Re: 1.3.4 status?

[Jonathan Kamens <jik at curl dot com>]

>  From: "Robert Collins" <robert.collins@itdomain.com.au>
>  Date: Tue, 23 Oct 2001 10:41:36 +1000
>  
>  So, I'd start of by hand checking the faulting line of assembly, to see
>  that is *should* work if everything where normal, and then work back
>  through the stack trace doing the same thing.

You're past my current level of knowledge -- the last time I tried to
read assembler code it was in college, and it wasn't x86 assembler
code, I can tell you that much.

All the same, right now I'm running a series of builds to see if I can
localize exactly which change checked into the repository caused the
problem to start happening.  I realize that given how random the
effects of compiler bugs and/or memory corruption can be, the change
that caused the problem to start happening may actually have nothing
to do with the problem, but it's as good a place to start as any.

Also, while I agree that there may be a compiler bug here, it seems
odd that a compiler bug would trash the stack so badly, and yet it
does look like the stack is trashed pretty badly.  In addition to the
missing calls in the stack, note also that thread 2 is completely
missing.  When I run the same program with a good DLL (i.e., one
compiled with -O2) and put a breakpoint in fhandler_console::read,
there *is* a thread 2 when the breakpoint gets hit.

Is it possible that one thread is destroying the console's tty
structure before another thread tries to use it?

  jik