Mail Archives: cygwin-developers/2001/10/22/20:38:16
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 AT curl DOT com>
To: <jik AT curl DOT com>
Cc: <cygwin-developers AT cygwin DOT 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
>
- Raw text -