Sorry for the long post. The bottom line question is: Is there any way to get the real location of a SIGSEGV when running gdb on a dumper.exe-generated core file or in just-in-time mode? When I interactively run my own program with "gdb -nw ./myprogram.exe" and a debug version of the cygwin1.dll, gdb gets the stack trace right when I call strcat(NULL, "hi") . Yes I do this on purpose, see the history below. However, if I setup the just-in-time feature to start up gdb or if I use dumper.exe to generate a core and then run gdb --core=corefile, I see a different stack trace with the frame that shows the real location of the failure missing (or cleverly concealed?) running inside GDB, purposely producing the above SIGSEGV: (gdb) bt #0 strcat (s1=0x0, s2=0x401044 "hi") at /work/build/src/newlib/libc/string/strcat.c:84 #1 0x40106b in main (argc=1, argv=0xa0147b0) at myprogram.c:6 #2 0x61003e77 in dll_crt0_1 () at /work/build/src/winsup/cygwin/dcrt0.cc:862 #3 0x61004111 in _dll_crt0 () at /work/build/src/winsup/cygwin/dcrt0.cc:928 #4 0x61004150 in dll_crt0 (uptr=0x0) at /work/build/src/winsup/cygwin/dcrt0.cc:940 #5 0x4010c3 in cygwin_crt0 () running outside gdb, invoking the dumper.exe to generated a myprogram.exe.core file, then running gdb --core=myprogram.exe.core I see the following. If I set up the just-in-time hook to kick off gdb.exe I see the same thing. (gdb) bt #0 0x77f82152 in _libkernel32_a_iname () #1 0x77e830fe in _libkernel32_a_iname () #2 0x77e83126 in _libkernel32_a_iname () #3 0x6100cf0c in try_to_debug () at /work/build/src/winsup/cygwin/exceptions.cc:372 #4 0x6100d700 in handle_exceptions (e=0x240fb34, in=0x240fb50) at /work/build/src/winsup/cygwin/exceptions.cc:531 #5 0x77f8e064 in _libkernel32_a_iname () #6 0x77f8e103 in _libkernel32_a_iname () #7 0x77f9f062 in _libkernel32_a_iname () #8 0x40106b in main (argc=1, argv=0x1a023684) at myprogram.c:6 #9 0x61003e77 in dll_crt0_1 () at /work/build/src/winsup/cygwin/dcrt0.cc:862 #10 0x61004111 in _dll_crt0 () at /work/build/src/winsup/cygwin/dcrt0.cc:928 #11 0x61004150 in dll_crt0 (uptr=0x0) at /work/build/src/winsup/cygwin/dcrt0.cc:940 #12 0x4010c3 in cygwin_crt0 () #13 0x40103d in mainCRTStartup () #14 0x77e992a6 in _libkernel32_a_iname () In particular, I really need to have entry #7 of the second trace to be something like: #7 strcat (s1=0x0, s2=0x401044 "hi") at /work/build/src/newlib/libc/string/strcat.c:84 Thanks in advance. Troy ...The history... in case anyone thinks I'm out of my mind (which I might be): I'm doing this expressly to learn how dumper.exe and gdb.exe work and interact so I can troubleshoot an intermittent cygwin1.dll problem we are seeing This all started before the 1.3.1 was released, but I should mention that the debug DLL that I'm presently using is built off the CVS sources from last night, and I also built with naked-bfd and naked-intl present so I could use the dumper.exe. Very nice tool! As I probably mentioned before, on some of my machines we have an intermittent problem with 1.1.8-2 with Dr. Watson sporadically popping up and reporting Access Violations in bash.exe, echo.exe, ls.exe, awk.exe, make.exe, and others. Which led me down this path of trying to troubleshoot the DLL. Since it's only happening on some of our machines and not others, I believe it's probably cygwin1.dll responding to some improper configuration. But I haven't been able to figure out what is different. I thought maybe if I could get a stack dump I could find out what the DLL doesn't like since I'm shooting in the dark right now. And since it's sporadic, I can't easily run gdb each time... I instead need to depend on just-in-time debugging session or core file dumper.exe to give me what I need. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple
