Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <02a201c15b5b$7910a4d0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Jonathan Kamens" <jik AT curl DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
References: <3BD4635D DOT 1060208 AT ece DOT gatech DOT edu> <20011022142729 DOT A10309 AT redhat DOT com> <20011022192430 DOT 3581 DOT qmail AT lizard DOT curl DOT com> <20011022193036 DOT 3609 DOT qmail AT lizard DOT curl DOT com> <20011022203136 DOT 5144 DOT qmail AT lizard DOT curl DOT com> <20011022203747 DOT 5162 DOT qmail AT lizard DOT curl DOT com>
Subject: Re: 1.3.4 status?
Date: Tue, 23 Oct 2001 10:41:36 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 23 Oct 2001 00:46:18.0533 (UTC) FILETIME=[209C7D50:01C15B5C]

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
>