[Openmcl-devel] YAWC (Yet Another Weird Crash)

[Ron Garret]

More info:

1.  The circumstances under which the crash occurs are not completely  
reproducible.  ~90% of the time it crashes when I try to switch a  
document to a new PDFView, but on a few occasions I do this and it  
doesn't crash, and on a few occasions it crashes without my having  
done this.

2.  If anything, wrapping things in gui::execute-in-gui makes the  
situation worse, not better.

3.  The behavior seems to be the same on the trunk and the 1.3 branch.

4.  I'm running 10.5.7

5.  My next step is try to reproduce this in pure ObjC.

rg


On May 28, 2009, at 4:40 PM, Ron Garret wrote:

> I tried wrapping all the run-time calls in both gui::execute-in-gui
> and easygui::run-on-main-thread (not at the same time of course) and I
> still see the same behavior.
>
> BTW, it's a really hard crash.  Sometimes it just quits without even
> bringing up the AltConsole.  Sometimes it brings up the AltConsole and
> spews and endless stream of "Unhandled exception 10" messages there.
>
> rg
>
> On May 28, 2009, at 4:28 PM, Gail Zacharias wrote:
>
>> Yup.  We have gui::execute-in-gui along the same lines.  We don't
>> have exports and documentation for the GUI package yet, but this will
>> be one of the first things to export once we do....
>>
>>
>> At 5/28/2009 07:07 PM, Raffael Cavallaro wrote:
>>
>>> On May 28, 2009, at 5:52 PM, Ron Garret wrote:
>>>
>>>> I've already checked the
>>>> obvious things like the reference counts on the PDF files dropping
>>>> to
>>>> zero and everything seems OK.
>>>
>>>
>>> I don't see the effect you're seeing - I've tried several times
>>> already. However, I notice you're doing gui things without ensuring
>>> they happen on the main thread. Could this be it? Apple want you to
>>> use performSelectorOnMainThread:withObject:yadaYadaYada & co.
>>>
>>> FWIW, I use this for all calls that frob GUI entities - it
>>> accomplishes the same thing, but unlike the above Cocoa call, it
>>> isn't
>>> limited to a single parameter:
>>>
>>> (in-package :ccl)
>>>
>>> (defmacro gui-do (&body body)
>>>  (let ((values-list (gensym "GUI-DO-VALUES-LIST"))
>>>        (sem (gensym "GUI-DO-SEMAPHORE")))
>>>    `(if (eq *current-process* ccl::*initial-process*)
>>>       (progn , at body)
>>>       (let* ((,sem (make-semaphore))
>>>              (,values-list nil))
>>>         (process-interrupt
>>>          ccl::*initial-process*
>>>          (lambda ()
>>>            (setq ,values-list (multiple-value-list (progn , at body)))
>>>            (signal-semaphore ,sem)))
>>>         (wait-on-semaphore ,sem)
>>>         (values-list ,values-list)))))
>>>
>>> I also have another version which doesn't wait for the return
>>> value(s)
>>> if you're interested.
>>>
>>> So calls to things like #/setContentView: I would wrap thus: (gui-do
>>> (#/setContentView: ... etc. just to ensure they happen on the main
>>> thread.
>>>
>>> Hopefully the Clozure crew will let me know if this is really
>>> wrongheaded.
>>>
>>> regards,
>>>
>>>
>>>
>>>
>>>
>>> Raffael Cavallaro
>>> raffaelcavallaro at me.com
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel