Daniel Barlow <dan@...> writes:
> David Lichteblau <david@...> writes:
>> (Except for a new, unrelated symptom (at least it seems to be new, but
>> since I do not even know how to reproduce it, it could be old). At some
> If it's the same one as I'm seeing, I don't think it is new; it was
> masked by the with-pinned-objects problems which tended to kick in
I'm not sure this is true, or if it is, some rearrangement has
happened whereby this problem is statistically much more likely.
>> point SBCL just halted and did not react anymore (not even to C-c).
>> Note that it was not idle at that point, but had one thread consuming
>> all CPU time. Is this is the same problem Christophe Rhodes reported?)
> If you connect gdb to the cpu-using thread at that point, you will
> probably find that it's waiting for all threads to stop (polling
> countdown_to_gc) so that it can garbage-collect them. There seems to
> be some circumstance in which it overcounts the number of threads that
> need stopping. Presently though I have no idea what.
So, after a certain amount of recompilation:
SBCL/threaded versions 0.8.3.84, 0.8.3.82 and 0.8.3.74 all exhibit the
following behaviour on trying to run a McCLIM example, or the CLIM
listener, or whatnot: some kind of odd error (a sigsegv + 10 NIL is
not of type SB-DI::FRAME , for instance), followed by a thread stuck
in gc_stop_the_world. CLX itself works fine, and a non-threaded build
likewise works fine.
Here's the rub, though: SBCL/threaded 0.8.3.49 does not exhibit this
problem. McCLIM windows come up and seem at least reasonably stable;
certainly, there's no instadeath like there is in later versions.
I hope this "helps" somewhat.
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)