[Bug python/12930] New: GDB state during gdb.Breakpoint::stop callback is unclear

[Bug python/12930] New: GDB state during gdb.Breakpoint::stop callback is unclear

[kevin.pouget at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12930

           Summary: GDB state during gdb.Breakpoint::stop callback is
                    unclear
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned@sourceware.org
        ReportedBy: kevin.pouget@gmail.com


GDB seems to be in a temporary state when gdb.Breakpoint::stop is called:
issuing gdb.execute("info threads") command highlights that the process is
viewed as running:

* 1    process 18244 "functionPtr" (running)

but some sequences of command (namely an "attach" in another inferior) will
revert to a "normal" state:

(gdb) r
Starting program: /home/kevin/travail/arm/perso/root/sample/debug/functionPtr 
  Id   Target Id         Frame 
* 1    process 18244 "functionPtr" (running)
Added inferior 2
[Switching to inferior 2 [process 0] (<noexec>)]

(SIGTTOU received)

0x0000003402e165c7 in open64 () from /lib64/ld-linux-x86-64.so.2
  Id   Target Id         Frame 
* 2    process 18251 "sleep" 0x0000003402e165c7 in open64 () from
/lib64/ld-linux-x86-64.so.2
  1    process 18244 "functionPtr" main () at ./functionPtr.c:8


it should be state somewhere a) what is allowed to do in `Breakpoint::stop'
function, or stabilize the state so that everything can be done

--

class MyBreakpoint(gdb.Breakpoint):
    def stop(self):
        gdb.execute("info threads")
        gdb.execute("add-inferior")
        gdb.execute("inferior 2")
        import subprocess
        sleep = subprocess.Popen(["sleep", "1000"])
        gdb.execute("attach %d" % sleep.pid)
        gdb.execute("info threads")

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12930] GDB state during gdb.Breakpoint::stop callback is unclear

[kevin.pouget at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12930

Kevin Pouget <kevin.pouget at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevin.pouget at gmail dot
                   |                            |com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12930] GDB state during gdb.Breakpoint::stop callback is unclear

[pedro at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12930

Pedro Alves <pedro at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro at codesourcery dot
                   |                            |com

--- Comment #1 from Pedro Alves <pedro at codesourcery dot com> 2011-06-24 13:44:29 UTC ---
"(running)" is correct here.  When the "stop" callback returns false, there
should be no running->stopped->running transition visible, exactly because your
callback claimed it didn't want the thread to "stop" (and nothing else wanted
it to stop).

>From the user/frontend's perspective, the thread is still running at this
point.  [The user should get an error if he tries to resume a thread that
is currently "running", irrespective of the thread happening to be presently
suspended due to having hit some internal event (e.g., internal single-step
event stops while handling a "s" command that requires several single-steps).]

Internal events are hidden from the user.  That's why we have running/stopped
independent of executing/not-executing in the thread's internal state.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12930] GDB state during gdb.Breakpoint::stop callback is unclear

[pedro at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12930

--- Comment #2 from Pedro Alves <pedro at codesourcery dot com> 2011-06-24 13:53:01 UTC ---
"attach" is a synchronous command.  You've effectively nested an event loop
within your "stop" callback (you'll see wait_for_inferior twice in the
backtrace).  The topmost wait_for_inferior will switch _all_ threads' state to
stopped when it finishes...
These scenarios make my head hurt with non-stop/async on...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12930] GDB state during gdb.Breakpoint::stop callback is unclear

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12930

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2011-10-07 13:23:23 UTC ---
CVSROOT:    /cvs/src
Module name:    src
Changes by:    pmuldoon@sourceware.org    2011-10-07 13:23:19

Modified files:
    gdb/doc        : ChangeLog gdb.texinfo 

Log message:
    2011-10-07  Phil Muldoon  <pmuldoon@redhat.com>

    PR python/12930
    PR python/12802

    * gdb.texinfo (Breakpoints In Python): Clarify behavior in the
    stop method.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/doc/ChangeLog.diff?cvsroot=src&r1=1.1221&r2=1.1222
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/doc/gdb.texinfo.diff?cvsroot=src&r1=1.870&r2=1.871

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12930] GDB state during gdb.Breakpoint::stop callback is unclear

[pmuldoon at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12930

Phil Muldoon <pmuldoon at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pmuldoon at redhat dot com
         Resolution|                            |FIXED
   Target Milestone|---                         |7.4

--- Comment #4 from Phil Muldoon <pmuldoon at redhat dot com> 2011-10-07 14:01:07 UTC ---
I have added a manual patch to describe what the limits of operations are at
this point.  If you don't agree this is enough, please re-open this bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.