Mail Archives: cygwin/2004/03/20/20:32:39
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/
- Raw text -