Re: trap to debugger when compiling from multiple threads
Gary Byers <[email protected]> Fri, 1 Aug 2003 06:06:34 -0600 (MDT)
| Newsgroups | gmane.lisp.openmcl.bugs |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 1 Aug 2003, Eric Marsden wrote:
> Hi,
>
> Loading the following code into OpenMCL causes it to break into the
> debugger. I see the same behaviour on Darwin and LinuxPPC, with recent
> CVS builds.
>
Thanks. I can reproduce this (and think that I understand what the
problem is.) If you insert a (FORCE-OUTPUT *DEBUG-IO*) right after
the FORMAT in WITH-SPAWNED-THREAD, you'll see that it dies as soon as
it pulls a recycled ("exhausted") thread out of the pool.
PROCESS-RESET is basically killing off the underlying native thread
and causing it to free up its stacks, but there's a leftover refernce
to the defunct native thread reachable from the process object.
PROCESS-PRESET thinks that the native thread exists, and tries to push
a lisp function on one of its stacks. (That stack doesn't exist anymore.)
Rather than killing the native thread, PROCESS-RESET should probably ...
reset it, so that it more-or-less looks like a newly-created native
threads (with stacks that're allocated but essentially empty.)
I'll try to fix this later today (and then we can see if anything more
subtle happens when multiple compilations are going on concurrently.)