[Openmcl-devel] 64bit drag and drop crash (was: HEMLOCK-LISTENER-FRAME (#x4060D0)> is not of the expected type CCL::STD-CLASS)

Gary Byers gb at clozure.com
Thu Sep 16 18:57:45 PDT 2010


I think that this means that the problem described in

<http://trac.clozure.com/ccl/ticket/715>

isn't just theoretical.

I haven't been able to provoke a GC crash yet, but I can fairly
reliably get the act of dragging some text around to generate a
floating-point exception, deep in the code that drags the selected
text around:


(gdb) bt
#0  0x00007fff83cd8882 in sseCGSBlackDeepMaskCopyARGB8888 ()
#1  0x00007fff83712d4e in argb32_mark ()
#2  0x00007fff829fa91d in ripl_BltGlyph ()
#3  0x00007fff829f91c4 in ripc_RenderGlyphs ()
#4  0x00007fff829f8877 in ripc_DrawGlyphs ()
#5  0x00007fff83719f67 in draw_glyphs ()
#6  0x00007fff8371986e in CGContextShowGlyphsWithAdvances ()
#7  0x00007fff872b612b in -[NSLayoutManager(NSTextViewSupport) showPackedGlyphs:length:glyphRange:atPoint:font:color:printingAdjustment:] ()
#8  0x00007fff872b5408 in -[NSLayoutManager(NSPrivate) _drawGlyphsForGlyphRange:atPoint:parameters:] ()
#9  0x00007fff8769431a in -[NSTextView(NSDragging) dragImageForSelectionWithEvent:origin:] ()
#10 0x00007fff87693725 in -[NSTextView(NSDragging) dragSelectionWithEvent:offset:slideBack:] ()
#11 0x00007fff87350c42 in -[NSTextView mouseDown:] ()
#12 0x000000000001b2cb in SPffcall () at ../x86-spentry64.s:4038

and that ticket describes what would happen if the GC runs (because of activity
in another thread) while we're processing that FP exception.

This happens in code invoked from the (CALL-NEXT-METHOD EVENT) call
near the end of the #/mouseDown: method on
HEMLOCK-TEXTSTORAGE-TEXT-VIEW in ccl:cocoa-ide;cocoa-editor.lisp.

If you change that to

(let* ((mxcsr-control (ccl::%get-mxcsr-control)))
     (unwind-protect
         (progn
           (ccl::%set-mxcsr-control #x1f80)
           (call-next-method event)) ; <- original code
       (ccl::%set-mxcsr-control mxcsr-control)))

and redefine the method, does dragging still lead to a GC crash ?  (For me,
it keeps the FP exceptions from being reported; the fact that Apple's code
does a multiply on an infinity isn't really that interesting, though it's
likely a bug in that code.)

Our handling of FP exceptions in foreign code changed (in the trunk) a few
months ago.  I think that the old code would have still reported the FP
exception (and I don't know what the consequences of that would be), but
the new code has a GC risk associated with it and I strongly suspect that
that's what you're running into.


On Thu, 16 Sep 2010, Alexander Repenning wrote:

> Silly me... copied the wrong line of code
> 
> Anyway, back to the original problem
> 
> Start up CCL32 Cocoa and drag any text, e.g. "Welcome to Clozure Common Lisp Version 1.6-dev-r14265M-trunk  (DarwinX8632)!"
> 
> works
> 
> but try CCL64 Cocoa "Welcome to Clozure Common Lisp Version 1.6-dev-r14265M-trunk  (DarwinX8664)!" 
>  
> 
> and you get some bad crash. Some GC problem:
> 
> Process:         dx86cl64 [16312]
> Path:            /Users/alex/ccl/Clozure CL64.app/Contents/MacOS/dx86cl64
> Identifier:      com.clozure.Clozure CL-x8664
> Version:         Version 1.4-dev (14265M-trunk (X8664))
> Code Type:       X86-64 (Native)
> Parent Process:  launchd [159]
> 
> Date/Time:       2010-09-16 18:43:43.620 -0600
> OS Version:      Mac OS X 10.6.4 (10F569)
> Report Version:  6
> 
> Interval Since Last Report:          2261929 sec
> Crashes Since Last Report:           29
> Per-App Interval Since Last Report:  44 sec
> Per-App Crashes Since Last Report:   4
> Anonymous UUID:                      FE6CA669-66FB-442C-A57B-0E75D1FDD264
> 
> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000030
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> 
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   com.clozure.Clozure CL-x8664   0x0000000000023e49 mark_xp + 9 (x86-gc.c:1486)
> 1   com.clozure.Clozure CL-x8664   0x000000000001e968 mark_tcr_xframes + 56 (gc-common.c:706)
> 2   com.clozure.Clozure CL-x8664   0x00000000000209e8 gc + 1544 (gc-common.c:1545)
> 3   com.clozure.Clozure CL-x8664   0x0000000000026f7f gc_from_tcr + 47 (x86-exceptions.c:2902)
> 4   com.clozure.Clozure CL-x8664   0x0000000000028759 gc_like_from_xp + 249 (x86-exceptions.c:2859)
> 5   com.clozure.Clozure CL-x8664   0x0000000000028848 gc_from_xp + 24 (x86-exceptions.c:2914)
> 6   com.clozure.Clozure CL-x8664   0x000000000002898c allocate_object + 300 (x86-exceptions.c:142)
> 7   com.clozure.Clozure CL-x8664   0x000000000002914f handle_alloc_trap + 111 (x86-exceptions.c:599)
> 8   com.clozure.Clozure CL-x8664   0x00000000000294d5 handle_exception + 773 (x86-exceptions.c:1137)
> 9   com.clozure.Clozure CL-x8664   0x00000000000298c6 signal_handler + 102 (x86-exceptions.c:1416)
> 10  com.clozure.Clozure CL-x8664   0x000000000002eb37 pseudo_sigreturn + 0 (x86-asmutils64.s:128)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sep 16, 2010, at 1:15 PM, Gary Byers wrote:
> 
> 
>
>       On Thu, 16 Sep 2010, Alexander Repenning wrote:
>
>             Exploring a crash resulting from dragging any text anywhere in a recent version of CCL I am trying to
>             build the latest one
>
>             without luck:
>
>             - (compile-ccl t) worked fine, after that I quit and launched CCL again
> 
>
>       Do (REBUILD-CCL :FULL T)
>
>             Welcome to Clozure Common Lisp Version 1.6-dev-r14118M-trunk  (DarwinX8632)!
>
>                                                       ^^^^^^^
>       Or you'll still be running something that's several weeks old.
> 
> 
> Prof. Alexander Repenning
> 
> 
> University of Colorado
> 
> Computer Science Department
> 
> Boulder, CO 80309-430
> 
> 
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
> 
> 
> 
> 
>


More information about the Openmcl-devel mailing list