This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: gdb and threads
- To: "'cygwin at sourceware dot cygnus dot com'" <cygwin at sourceware dot cygnus dot com>
- Subject: Re: gdb and threads
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Thu, 22 Jun 2000 17:11:00 -0400
- References: <61891BA043DED21180920090273F1738E18E72@TNINT06>
- Reply-To: cygwin at sourceware dot cygnus dot com
On Thu, Jun 22, 2000 at 04:59:52PM -0400, Arlen Barr wrote:
>Are threads fully supported with the cygwin gdb?
Yes. Thread 1 is normally the main thread. Thread 2 is normally the
signal handling thread and is maintained by gdb. Thread 3 can be a
thread for handling processes if any have been forked or execed.
I use gdb to debug what's going on in thread 2 all of the time.
Other threads pop up when there is a Windows signal or exception.
This is standard Windows behavior.
Btw, if you are not already doing so, you should be running the
newest cygwin version of gdb.
>I'm stepping through code, and although gdb reports only one thread
>(well it lists two, but the first one does not refer to any source
>file), execution suddenly jumps to a point in libstdc++ (version
>2.10.0) without any apparent reason (and then procedes to segmentation
>fault). The code crashes at seemly random places (in my code) leading
>me to believe that a cygwin library has spawned a thread which is
>crashing.
If cygwin was spawning a random thread it would be dying somewhere in
the cygwin DLL, not in your code.
I don't have any further insight into what is going on here. Offhand
it sounds like stack corruption.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com