Re: more problems from MT debugger/stack overflow => segfault

[<don...@is...>]

Vladimir Tzankov writes:
 > You are closing the socket too early!
(ah, one of the few places where moving something later in the code
causes it to happen earlier in the execution!)

 > However having segfaults even in this case (read from closed socket)
 > is not good. Will check.
I suspect the next message explains what's happening here.
If each complaint about the closed stream leads to an attempt to enter
the debugger, and the debugger tries to print to the same stream which
causes another error, then we get a stack overflow, and since it's
occuring in a non-main thread, that causes the segfault.

Vladimir Tzankov writes:
 > On 3/6/11, Don Cohen <don...@is...> wrote:
 > > I send this on the theory that any segfault qualifies as a clisp bug.
 > > This is with current source.  On non-MT I get
 > >   *** - Program stack overflow. RESET
 > > whereas in MT I get segfault.
 > 
 > With MT - only the "main thread" (first one) has stack overflow detection.
 > Stack overflow detection/recovery is implemented via libsigsegv and it
 > supports single stack range.
 > May be libsigesgv should be enhanced with multiple stack range support? ?

A few thoughts on this.
- Perhaps there's some shorter term solution involving checking when 
doing at least some operations that use more stack?
- I thought there was something similar used for generational GC, which
I imagined was going to need to detect writes to arbitrary sets of pages.
- It would be useful for debugging if we could get a lisp error BEFORE
the overflow, say, when you exceed half of the available stack and
then again when you exceed 3/4, etc.