PDF crash

[gb]

Details in the email thread starting at  http://clozure.com/pipermail/openmcl-devel/2009-May/009629.html.

[gb]

Crash Reporter log

[gb]

I was able to get this to crash in a way that bypassed the kernel debugger and generated the enclosed crash log.

Thread 0 (the event thread) was responding to a click in the scroll bar of a window displaying a PDF view and wound up in the guts of malloc().

Thread 5 (the thread that got the segfault) is an NSThread that was apparently trying to create an autorelease pool; it seems to have died at the same location inside the guts of malloc.

The thread that crashed wasn't created by lisp and therefore had never had Mach thread-level exception handling installed, which explains why the kernel debugger was bypassed.

[gb]

Doing:

# I use tsch; bash users should set env vars via "export VAR[=VALUE]", IIRC.
shell> cd Clozure\ Cl-x8664.app/Contents/MacOS
shell> setenv MallocScribble
shell> setenv MallocCheckStart 1000
shell> ./dx86cl64

and then running the test case generated

dx86cl64(99396,0x7fff701cc700) malloc: MallocCheckHeap: PASSED check at 397000th operation
dx86cl64(99396,0x7fff701cc700) malloc: MallocCheckHeap: PASSED check at 398000th operation
dx86cl64(99396,0x7fff701cc700) malloc: *** error for object 0x9fa200: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
dx86cl64(99396,0x7fff701cc700) malloc: *** error for object 0x9fa200: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
dx86cl64(99396,0x7fff701cc700) malloc: *** previous incorrectly set grain=2  count=1 ptr=0x9fa200
dx86cl64(99396,0x7fff701cc700) malloc: *** small free list incorrect (grain=2) szone_check_all() counter=398
*** error: check: small free list incorrect
*** set a breakpoint in malloc_error_break to debug
dx86cl64(99396,0x7fff701cc700) malloc: *** MallocCheckHeap: FAILED check at 399000th operation
dx86cl64(99396,0x7fff701cc700) malloc: Stack for last operation where the malloc check succeeded: 0x7fff810e1172 0x7fff810180f3 0x7fff80b6790c 0x7fff80b678c6 0x7fff80b6af8b 0x7fff80ab541f 0x7fff80ab5205 0x7fff80ab4603 0x7fff80b6abeb 0x7fff80b6aa43 0x14020086 0x1401d410 0x1401ad49 0x14044d28 0x7fff81ed2d59 0x7fff81ed2d59 0x7fff81ed2d59 0x7fff81ed2d59 0x7fff81e43d33 0x7fff81e112f6 0x1be87 0x442df0 0x442e68 0x442f28 0x100810 
(Use 'atos' for a symbolic stack)
dx86cl64(99396,0x7fff701cc700) malloc: *** Recommend using 'setenv MallocCheckHeapStart 398000; setenv MallocCheckHeapEach 100' to narrow down failure
dx86cl64(99396,0x7fff701cc700) malloc: *** Sleeping for 100 seconds to leave time to attach
Unhandled exception 10 at 0x7fff8101af8a, context->regs at #x7fff5fbfb1d0
Exception occurred while executing foreign code
 at malloc_default_zone + 224
? for help
[99396] Clozure CL kernel debugger: 

e.g., malloc heap corruption, the first symptom of which (at least the first that was detected by these options) was an apparent write to freed memory.

I got this by scrolling a PDF view at a point where Ron's message indicated that things should be OK; I tried to reproduce this a bit later and wasn't able to provoke the crash, so this seems to be somewhat timing-sensitive.

I didn't try to force anything to run in the main thread, and I'm still somewhat suspicious that that failure to do so may have something to do with this. If so, it seems like the crash is a delayed reaction to whatever the cause is.

[gb]

I tried wrapping most of the code that sets views and installs PDF documents in them inside (GUI::EXECUTE-IN-GUI (lambda () ...)) forms and as Ron reported it would still crash.

I then (additionally) forced the (objc:load-framework ...) call to happen on the main thread and have not yet been able to get it to crash.

That isn't really definitive - the crash seems to be timing-sensitive - but it wouldn't shock me if some initialization code in Quartz or its subframeworks assumed that it was running on the main thread and misbehaves if that assumption turns out to be false.

[gb]

crash report from objc version

[gb]

The second attachment above shows a crash log from an ObjC program that does similar things to what the test case does; it seems to crash in the same way.

An Xcode project that contains that ObjC program (er, a feeble attempt at an ObjC program) is available in  ftp://clozure.com/pub/pdf-test.zip. I don't know whether either the ObjC code or the orginal lisp code are doing kosher things or not, but there doesn't seem to be any reason to think that this has anything to do with CCL.