Re: Creating core dumps and gdb tracing...

[Chris Faylor <cgf at cygnus dot com>]

On Sat, Oct 07, 2000 at 05:41:22PM -0500, Shelby Cain wrote:
>Consider a simple program like so:
>
>int main()
>{
>    char * foo = 0;
>    crashme(foo);
>}
>
>int crashme(char * cp);
>{
>    strcpy(cp, "KABOOM!!");
>}
>
>Compiling and linking it under W2K using cygwin produces an executable that
>does not produce a core file when it crashes.  One way around this would be
>to run it via gdb (ie: gdb crashme.exe) which will allow me to catch the
>offending statement.  However, I would really prefer a core file to work
>with as I don't have to "recreate" the situation in order to see what is
>going on.
>
>Regardless, when I use gdb to catch the seg fault... the stack window isn't
>providing me with any useful information.  When I open up the gdb console
>and try "backtrace" I get something to the effect of:
>
>"Error: #0  0x61070850 in _size_of_stack_reserve__ ()
>Cannot access memory at address 0x2000000"

You're probably not in thread 1.  cygwin is multi-threaded.  The main thread
is usually thread 1.

Type "thread 1" command in gdb and then see if 'bt' shows anything.  If it
doesn't, it's probably because most Microsoft API functions don't have a
frame pointer.  If you're stuck in one of those, then the stack will be
screwed up.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com