Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Sat, 20 Mar 2004 20:32:09 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Minimal test case for Make crash bug
Message-ID: <20040321013209.GA12357@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <405C00BF DOT 3090507 AT kegel DOT com> <405C06C4 DOT 7030508 AT kegel DOT com> <405C6C4B DOT 90409 AT kegel DOT com> <405C939E DOT 5020909 AT kegel DOT com> <405C9695 DOT 2010609 AT kegel DOT com> <405CAFB8 DOT 5000209 AT kegel DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <405CAFB8.5000209@kegel.com>
User-Agent: Mutt/1.4.1i

On Sat, Mar 20, 2004 at 12:55:20PM -0800, Dan Kegel wrote:
>Dan Kegel wrote:
>>Sadly, error_start didn't seem to be able to start gdb:
>
>Thanks to Igor for pointing out that error_start must be a
>DOS path.  Here's what I see once I correct that:
>
>$ export CYGWIN=error_start:C:\\cygwin\\bin\\gdb.exe
>$ make
>...
>(gdb) bt
>#0  0x77f75a59 in ntdll!DbgUiConnectToDbg ()
>   from /cygdrive/c/WINDOWS/System32/ntdll.dll
>#1  0x77f5f31f in ntdll!KiUserCallbackDispatcher ()
>   from /cygdrive/c/WINDOWS/System32/ntdll.dll
>#2  0x00000005 in ?? ()
>#3  0x00000004 in ?? ()
>#4  0x00000001 in ?? ()
>#5  0x006effd0 in ?? ()
>#6  0x82ba40e8 in ?? ()
>#7  0xffffffff in ?? ()
>#8  0x77fa88f0 in wcstombs () from /cygdrive/c/WINDOWS/System32/ntdll.dll
>
>Unfortunately, that's also about what I see when I do
>$ export CYGWIN=error_start:C:\\cygwin\\bin\\gdb.exe
>$ ./a.exe

>where a.exe is the following compiled with cygwin's gcc:
>#include <stdio.h>
>int main(int argc, char **argv)
>{
>        int *x;
>        x = 0;
>        printf("Null is %d\n", *x);
>}
>
>Looking at the other two threads (why are there three?)
>doesn't help.

Cygwin is a multi-threaded application.  Thread 1 would be the thread
which is having difficulties in this case.  The above stack trace is for
the thread that gets created when a debugger attaches to a process.  If
you type 'c' in gdb you should see where the real error is occurring.
Of course, since the error is in the cygwin DLL, you won't see the
source lines unless you rebuild the DLL with debugging.

FWIW, I can't duplicate this problem.  The stack trace would indicate
an OOM situation wrt cygwin's heap (which is separate from the program
heap) but if that was the case cygwin should have issued an error.
--
Christopher Faylor
Cygwin Project Leader
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/