Bug 14018

Summary: Win32 fails to continue with "winerr 5" (pc register not available) after SigTrap while process paused
Product: gdb Reporter: Martin <gdb.bugs>
Component: win32Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: andre.poenitz, brobecker, david.schulz, orgads
Priority: P2    
Version: 7.4   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: pascal (src and bin) for reproducing

Description Martin 2012-04-24 22:45:20 UTC
Created attachment 6366 [details]
pascal (src and bin) for reproducing

This bug appears to be a regression. It is present it 7.3 and 7.4. But was not in previous 7.x)

On Windows in order to pause a running process for debugging, it is custom to call 
CreateRemoteThread(handle_to_debugged_process, 0,0, GetProcAddress(hMod, 'DebugBreak') ...)

This leads to GDB reporting:
*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame=


However if the above happens, while the app is already paused (e.g. after reaching a breakpoint) then the app can not be continued.
This can not always be avoided. It may happen as a race condition, where the breakpoint is hit, just before the signal could be sent.

The first continue will correctly lead to another pause/interrupt reporting the SigTrap.
Trying to continue from this will report 

-exec-continue
&"warning: SuspendThread failed. (winerr 5)\n"
^error,msg="PC register is not available"

-exec-continue
&"warning: SuspendThread failed. (winerr 5)\n"
^error,msg="PC register is not available"


**** To reproduce (using Free Pascal)  Win 32 / Vista (probably any other too) intel

I have included a helper app (in pascal) to trigger the SigTrap (source and bin).
Compile with:  fpc.exe dbgbrk.pas 

The app to be debugged is test.exe 
compile:   fpc.exe -g test.pas

Run gdb:
   gdb -i mi test.exe

-break-insert test.pas:4
-exec-run

~"Starting program: B:\\dbg\\test.exe \n"
=thread-group-started,id="i1",pid="8372"
=thread-created,id="1",group-id="i1"
~"[New Thread 8372.0x26c4]\n"
....
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x004013f9",func="FOO"

Take the PID reported by gdb (in the example 8372) and run (while the app is paused at the break point)

   dbgbrk.exe 8372


-exec-continue

^running
....
*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",

-exec-continue
^running
....
&"warning: SuspendThread failed. (winerr 5)\n"
^error,msg="PC register is not available"


-exec-continue
&"warning: SuspendThread failed. (winerr 5)\n"
^error,msg="PC register is not available"
Comment 1 Andre' 2012-11-01 14:39:38 UTC
Also reported for GDB 7.4.1, Windows XP SP3, see https://bugreports.qt-project.org/browse/QTCREATORBUG-7840
Comment 2 Orgad Shaneh 2013-09-09 13:27:05 UTC
Still happens with 7.6.1 on Windows 7.
Comment 3 David Schulz 2013-11-21 14:35:38 UTC
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).
Comment 4 cvs-commit@gcc.gnu.org 2014-04-19 08:20:51 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  17617f2d366ca969ccbc784be4f75931a1afd20f (commit)
      from  5723a6fd0636bed6d278ab19f6ead31d748a7a78 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=17617f2d366ca969ccbc784be4f75931a1afd20f

commit 17617f2d366ca969ccbc784be4f75931a1afd20f
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Apr 19 11:12:19 2014 +0300

    PR gdb/14018 -- avoid "PC register not available" errors.
    
    gdb/windows-nat.c (thread_rec): Don't display a warning when
    SuspendThread fails with ERROR_ACCESS_DENIED.  If SuspendThread
    fails for any reason, set th->suspended to -1, so that we don't
    try to resume such a thread.  Also, don't return NULL in these
    cases, to avoid completely ruin the session due to "PC register is
    not available" error.
    (do_windows_fetch_inferior_registers): Check errors in
    GetThreadContext call.
    (windows_continue): Accept an additional argument KILLED; if not
    zero, ignore errors in the SetThreadContext call, since the
    inferior was killed and is shutting down.
    (windows_resume, get_windows_debug_event)
    (windows_create_inferior, windows_mourn_inferior)
    (windows_kill_inferior): All callers of windows_continue changed
    to adjust to its new calling sequence.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog     |   19 +++++++++++++++++++
 gdb/windows-nat.c |   49 +++++++++++++++++++++++++++++++++----------------
 2 files changed, 52 insertions(+), 16 deletions(-)
Comment 5 cvs-commit@gcc.gnu.org 2014-04-19 08:27:08 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, gdb-7.7-branch has been updated
       via  230109e7ff8ad9b1268d251cba1fa26a24efde64 (commit)
      from  b4a18502ba8e066d0862ecc0ce5bb4d16eafdbbf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=230109e7ff8ad9b1268d251cba1fa26a24efde64

commit 230109e7ff8ad9b1268d251cba1fa26a24efde64
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Apr 19 11:12:19 2014 +0300

    PR gdb/14018 -- avoid "PC register not available" errors.
    
    gdb/windows-nat.c (thread_rec): Don't display a warning when
    SuspendThread fails with ERROR_ACCESS_DENIED.  If SuspendThread
    fails for any reason, set th->suspended to -1, so that we don't
    try to resume such a thread.  Also, don't return NULL in these
    cases, to avoid completely ruin the session due to "PC register is
    not available" error.
    (do_windows_fetch_inferior_registers): Check errors in
    GetThreadContext call.
    (windows_continue): Accept an additional argument KILLED; if not
    zero, ignore errors in the SetThreadContext call, since the
    inferior was killed and is shutting down.
    (windows_resume, get_windows_debug_event)
    (windows_create_inferior, windows_mourn_inferior)
    (windows_kill_inferior): All callers of windows_continue changed
    to adjust to its new calling sequence.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog     |   19 +++++++++++++++++++
 gdb/windows-nat.c |   49 +++++++++++++++++++++++++++++++++----------------
 2 files changed, 52 insertions(+), 16 deletions(-)
Comment 6 Joel Brobecker 2014-04-21 15:40:17 UTC
As per commits.
Comment 7 cvs-commit@gcc.gnu.org 2014-05-05 21:54:13 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The annotated tag, gdb-7.7.1-release has been created
        at  af2cd04ccdd7631f4009b2aef5c8402b97d732e6 (tag)
   tagging  4bd8fc3a1362970d9800a263987af8093798338b (commit)
  replaces  gdb-7.7-release
 tagged by  Joel Brobecker
        on  Mon May 5 14:53:19 2014 -0700

- Log -----------------------------------------------------------------
GDB 7.7.1 Release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEABECAAYFAlNoCE8ACgkQku2wS/8yXPMbgQCgiCmLYGN3tjnqEEc0Y0i4iCHj
RN8AnRgphFx5RnfZ5TSUHgC6mVHel7sC
=xfEO
-----END PGP SIGNATURE-----

Eli Zaretskii (1):
      PR gdb/14018 -- avoid "PC register not available" errors.

GDB Administrator (88):
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in

Jan Kratochvil (3):
      Fix Python stack corruption
      PR gdb/16626
      PR gdb/16626

Joel Brobecker (3):
      Document the GDB 7.7 release in gdb/ChangeLog
      Bump GDB version number to 7.7.0.DATE-cvs.
      Set GDB version number to 7.7.1.

Nick Clifton (1):
      Following up on Tom's suggestion I am checking in a patch to replace the various

Pedro Alves (3):
      Make sure we don't resume the stepped thread by accident.
      PR gdb/16575: stale breakpoint instructions in the code cache
      AIX 32-bit core loading, high section addresses.

Pierre Langlois (1):
      Erroneous backtrace on AVR.

Rainer Orth (1):
      PR build/16550

-----------------------------------------------------------------------