[Bug win32/14018] Win32 fails to continue with "winerr 5" (pc register not available) after SigTrap while process paused

["david.schulz at digia dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14018

David Schulz <david.schulz at digia dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.schulz at digia dot com

--- Comment #3 from David Schulz <david.schulz at digia dot com> ---
Can also be reproduced with the following C++ Code:

#include <windows.h>

int main()
{    
    while (true)
        DebugBreakProcess(GetCurrentProcess());
}

Start gdb:

gdb -ex run <Executable of the code above>.exe

After startup enter:

break main.cpp:6
command
continue
end
handle SIGTRAP nostop
continue

After some lines telling you that the program received a SIGTRAP the following
error is shown:
&"warning: SuspendThread failed. (winerr 5)\n"
^error,msg="PC register is not available"

The breakpoint is important because SuspendThread is just called when the gdb
requests the thread contexts (see gdb/windows-nat.c:thread_rec()). 

The gdb commands and the code above actually emulates the QtCreator which
inserts a breakpoint to a running inferior, and this breakpoint is hit directly
after it was inserted.
To give you a time line of the QtCreator behavior:
 - everything runs (QtCreator, gdb, inferior)
 - request insert breakpoint
 - interrupt inferior
 - wait for gdb to tell QtCreator it has stopped
 - insert breakpoint
 - tell the gdb to continue execution
 - breakpoint in inferior is hit
 - BOOM: gdb stops with the error message: PC register is not available

The actual problem is that the gdb has not the rights to suspend the Thread
(winerr 5 == ERROR_ACCESS_DENIED). As the only threads in this process are the
main thread and the DebugBreak threads it looks like the gdb has not the rights
to suspend the DebugBreak threads in some states (it occures not on every break
so it has to be a special thread state). 
A possible Solution could be to check if you have the rights to suspend that
thread (should be done anyway according to the documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686345(v=vs.85).aspx).

-- 
You are receiving this mail because:
You are on the CC list for the bug.