Question about gdb --core and just-in-time gdb stack backtraces...

[Troy Noble <troy dot noble at channelpoint dot com>]

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