[Openmcl-devel] Trace/BPT trap in 1.0

[Gary Byers]

I'll try to look at this in more detail tonight, but very (very) briefly:

- if a thread is created by lisp code (MAKE-PROCESS or PROCESS-RUN-FUNCTION),
   it gets per-thread exception set up for it for -most- machine-level
   exceptions.

   That per-thread exception handling will cause entry to the kernel
   debugger if the exception isn't handled.  (A lot of exceptions indicate
   lisp-level errors or "exceptional" but non-fatal situations, like
   not having memory to cons in at the moment.)

- if a thread's created by foreign code and calls into lisp, the same
   per-thread exception handling -should- get up just before the first
   callback occurs.  (This is how it's -supposed- to work, but it's
   been a while since I've tested that.)

- in OSX, Carbon Time Manager tasks run in their own thread.

- the per-thread exception-handling mechanism depends on having a
   foreign thread listen for "exception messages" from the OS kernel.
   Nothing handles exceptions for that thread.

- an exception that's not handled in the thread that it occurs in
   usually causes the program to terminate with a terse error message.

If I had to guess, I'd guess that an exception was happening in the
thread running the Time Manager task, either in the foreign code
before the first callback or because the exception handling wasn't
established correctly when the first callback was made.

The fact that the code worked in earlier versions (this is all
-supposed- to work ...) suggests that I broke something in the
code that (among other things) sets up exception handling for
a foreign thread.  Like I said, I'll try to look at it this
evening.

On Wed, 30 Nov 2005, todd ingalls wrote:

> Hi I was wondering if anyone could help me diagnose this problem.
>
> In pre 1.0 version of openmcl the code below ran fine. This is a simplified
> version of a high resolution timer.
>
> In 1.0 version of openmcl, i get a Trace/BPT trap error and dppcl dies.
>
> I have traced the problem down to the call to #_PrimeTimeTask, but can't seem
> to figure out what to do from there. Does anyone have any suggestions in
> regards to what I should do next to determine why this is happening?
>
> thanks
>
> PS. I am running OSX 10.3.9.
>
>
> (ccl::open-shared-library "Carbon.framework/Carbon")
> (ccl::use-interface-dir :carbon)
>
> (progn
>  (defparameter *tmtask* nil)
>  (defparameter *counter* 0)
>  (if *tmtask*
>      (progn
> 	(#_RemoveTimeTask *tmtask*)
> 	(#_DisposeTimerUPP (ccl::pref *tmtask* :<TMT>ask.tm<A>ddr))))
>  (setf *tmtask* (ccl::make-record :<TMT>ask))
>  (setf (ccl::pref *tmtask* :<TMT>ask.tm<W>ake<U>p) 0)
>  (setf (ccl::pref *tmtask* :<TMT>ask.tm<R>eserved) 0)
>
>  (ccl::defcallback time-task-callback (:<TMT>ask<P>tr tmTaskPtr)
>    (if (> (incf *counter*) 100)
> 	(progn
> 	  (#_RemoveTimeTask tmTaskPtr)
> 	  (#_DisposeTimerUPP (ccl::pref tmTaskPtr :<TMT>ask.tm<A>ddr)))
>      (#_PrimeTime tmTaskPtr 1)))
>
>  (setf (ccl::pref *tmtask* :<TMT>ask.tm<A>ddr)
> 	(#_NewTimerUPP time-task-callback))
>  (#_InstallXTimeTask *tmtask*)
>  (#_PrimeTime *tmtask* 1))
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>