I have a single-threaded executable that has a number of debug-print
routines that can be called interactively in the debugger to display
data structures to stderr. Something has changed in gdb/gcc/Cygwin
during the last year or so (I don't update my installation very often)
so that when I call one of these functions, _sometimes_ gdb will start
a new thread and put my current thread into "running" status, so that
I can't step, etc. (although the thread isn't actually running).
Here's the scenario:
1) I say "gdb xxx.exe", set a breakpoint, and run. When I hit the
breakpoint, "info threads" shows me two threads, one for my executable
and one with some _cygtls/cygthread/ntdll frames; both are stopped.
2) I say "up" a couple of times, then "p db_foo(p)" (where db_foo is
one of these debug-print routines that displays to stderr the data
structure pointed to by "p"). Sometimes, but not always, gdb will
respond with
[New Thread 1436.0x1f00]
and although a "bt" will show the stack as still stopped at the
breakpoint, "info threads" will show all threads as "(running)", and
typing "n" is met with the error,
Cannot execute this command while the selected thread is running.
(Actually, for the first time just now, while running my scenario to
make sure I got all the details right for this email, I saw gdb start
a new thread in response to a "next" command --
(gdb) n
[New Thread 1436.0x1a0c]
after I had done a "p db_foo(p)" a couple of times without seeing a
new thread created, so apparently it's not just invoking one of these
debug-print functions that can result in this behavior.)
Changing to one of the newly-created threads reveals this stack trace:
#0 0x7733df6c in ntdll!ZwWaitForWorkViaWorkerFactory () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x77320153 in ntdll!RtlRunOnceBeginInitialize () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x6100626b in _cygtls::call2(unsigned long (*)(void*, void*),
void*, void*) () from /usr/bin/cygwin1.dll
#3 0x61006306 in _cygtls::call(unsigned long (*)(void*, void*),
void*) () from /usr/bin/cygwin1.dll
#4 0x610828d8 in threadfunc_fe(void*) () from /usr/bin/cygwin1.dll
#5 0x74be7c04 in KERNEL32!BaseThreadInitThunk () from
/c/WINDOWS/SYSTEM32/KERNEL32.DLL
#6 0x7735ad1f in ntdll!RtlInitializeExceptionChain () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#7 0x7735acea in ntdll!RtlInitializeExceptionChain () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#8 0x00000000 in ?? ()
Any ideas on what I can do to avoid this annoying behavior or to
regain control of my debugging session after it occurs? I'm running
32-bit Cygwin on Windows 8.1.
Thanks.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
