Re: 1.3.4 status?

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

My 2c on this is that this could be a lot worse than a malloc issue...
even though it is occuring at process exit.

GCC optimisation can change the code substantially as you step up
layers.

i.e. on common problem squid had was that a function ended up XOR'ing
variable foo with itself, before trying to use it! (Oh, it was _not_
meant to be 0). That resulted in the *BSD's requiring special configure
lines to disable -O2 for that OS release, and yet another gcc version
test in the configure script.

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. If you get past the exit()
stuff, then malloc is a thing to try. I'm not sure which is faster, this
is just my 2c.

Rob

----- Original Message -----
From: "Jonathan Kamens" <jik@curl.com>
To: <jik@curl.com>
Cc: <cygwin-developers@cygwin.com>
Sent: Tuesday, October 23, 2001 6:37 AM
Subject: Re: 1.3.4 status?


> I got a crash inside gdb, but like I said, the stack trace looks
> pretty useless.  Here's what it says:
>
>   (gdb) run
>   Starting program: /usr/bin/ps.exe
>         PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>         192       1     192        192    0  500 16:34:20
/cygdrive/c/cygdeb/gdb
>          58       1      58         58    1  500 16:34:27 /usr/bin/ps
>
>   Program received signal SIGSEGV, Segmentation fault.
>   [Switching to thread 58.0xb5]
>   0x61017c92 in fhandler_console::read (this=0x61017c71,
pv=0x1a43fe6c,
>       buflen=256) at
/u/jik/cygwin-cvs/src/winsup/cygwin/fhandler_console.cc:204
>   204       HANDLE h = get_io_handle ();
>   Current language:  auto; currently c++
>   (gdb) thread apply all where
>
>   Thread 3 (thread 58.0xb5):
>   #0  0x61017c92 in fhandler_console::read (this=0x61017c71,
pv=0x1a43fe6c,
>       buflen=256) at
/u/jik/cygwin-cvs/src/winsup/cygwin/fhandler_console.cc:204
>   #1  0x00000000 in ?? ()
>
>   Thread 1 (thread 58.0xc1):
>   #0  0x77f682db in ?? ()
>   #1  0x77f04f37 in ?? ()
>   #2  0x61079fa4 in tty_list::terminate (this=0xa00000c)
>       at /u/jik/cygwin-cvs/src/winsup/cygwin/tty.cc:144
>   #3  0x6107af3a in tty_terminate ()
>       at /u/jik/cygwin-cvs/src/winsup/cygwin/tty.cc:98
>   #4  0x61004f8a in do_exit (status=0)
>       at /u/jik/cygwin-cvs/src/winsup/cygwin/dcrt0.cc:969
>   #5  0x61005587 in _exit () at
/u/jik/cygwin-cvs/src/winsup/cygwin/dcrt0.cc:983
>   #6  0x610943d9 in exit () at
/u/jik/cygwin-cvs/src/newlib/libc/stdlib/exit.c:70
>   #7  0x61004a07 in dll_crt0_1 ()
>       at /u/jik/cygwin-cvs/src/winsup/cygwin/dcrt0.cc:769
>   #8  0x61004cd5 in _dll_crt0 ()
>       at /u/jik/cygwin-cvs/src/winsup/cygwin/dcrt0.cc:850
>   #9  0x6100546c in dll_crt0 (uptr=0x0)
>       at /u/jik/cygwin-cvs/src/winsup/cygwin/dcrt0.cc:862
>   #10 0x00402347 in _size_of_stack_reserve__ ()
>   #11 0x0040103d in _size_of_stack_reserve__ ()
>   #12 0x77f1b9ea in ?? ()
>   0x61017c92      204       HANDLE h = get_io_handle ();
>   (gdb)
>
> I'm going to try --malloc-debugging now.
>
>   jik
>