[Bug threads/14618] New: scheduler-locking doesn't work with gdbserver

[Bug threads/14618] New: scheduler-locking doesn't work with gdbserver

[tom.tan at analog dot com]

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

             Bug #: 14618
           Summary: scheduler-locking doesn't work with gdbserver
           Product: gdb
           Version: 7.4
            Status: NEW
          Severity: critical
          Priority: P2
         Component: threads
        AssignedTo: unassigned@sourceware.org
        ReportedBy: tom.tan@analog.com
    Classification: Unclassified


I got this when running the gdb test case "gdb.threads/no-unwaited-for-left"
with remote target(gdbserver).

Everytime if I "set scheduler-locking on" in gdb and then resume from a thread,
the other threads will also be resumed. I think the "on" mode should only
resume the current thread.

-- 
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 threads/14618] scheduler-locking doesn't work with gdbserver

[tom.tan at analog dot com]

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

Tom Tan <tom.tan at analog dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tom.tan at analog 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 threads/14618] scheduler-locking doesn't work with gdbserver

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> 2012-09-25 11:42:03 UTC ---
scheduler-locking does work with gdbserver, otherwise schedlock.exp would fail.

... but only as long as the thread being debugged doesn't exit.
This is the "TARGET_WAITKIND_NO_RESUMED / graceful leader-exits" point in

http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity

The GDB side fix (that added TARGET_WAITKIND_NO_RESUMED and those
testcases was <http://sourceware.org/ml/gdb-patches/2011-10/msg00704.html>.

When the (only) running thread exits, I think gdbserver ends up resuming the
whole inferior...

-- 
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 threads/14618] gdbserver also exits after a thread exits if "set scheduler-locking on"

[tom.tan at analog dot com]

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

Tom Tan <tom.tan at analog dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|scheduler-locking doesn't   |gdbserver also exits after
                   |work with gdbserver         |a thread exits if "set
                   |                            |scheduler-locking on"

--- Comment #2 from Tom Tan <tom.tan at analog dot com> 2012-09-26 07:58:29 UTC ---
Sorry, the title really doesn't describe the problem accurately. And thanks
Pedro for the wiki page, I missed that doc.

In no-unwaited-for-left.exp, if scheduler-locking is set to be "on", then after
the running thread exits, GDB server exits instead of the inferior is
resumed(my former description is not exact either). I set a break point after
the new thread exits and it doesn't execute to that code. 

I followed the code a bit and found that the last_status of gdbserver is
TARGET_WAITKIND_EXITED after the thread exits, then the process is mourned.

-- 
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 threads/14618] gdbserver also exits after a thread exits if "set scheduler-locking on"

[palves at redhat dot com]

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

--- Comment #3 from Pedro Alves <palves at redhat dot com> 2012-09-26 17:14:29 UTC ---
Right.  As I said, GDBserver ends up resuming all threads of the inferior if
the single thread that had been resumed exits.

In this case, after the inferior has been resumed, it naturally exits.
And when the inferior exits, then GDBserver exits as well; that much is normal.

The bit that decides to resume the inferior has this comment, in linux-low.c:

  /* If we were only supposed to resume one thread, only wait for
     that thread - if it's still alive.  If it died, however - which
     can happen if we're coming from the thread death case below -
     then we need to make sure we restart the other threads.  We could
     pick a thread at random or restart all; restarting all is less
     arbitrary.  */

This is of course, totally bogus.

The right fix it to add support for the new TARGET_WAITKIND_NO_RESUMED event
type to the remote protocol, and teach gdbserver to use it.

-- 
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 threads/14618] gdbserver, scheduler-locking, thread exits and TARGET_WAITKIND_NO_RESUMED

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gdbserver also exits after  |gdbserver,
                   |a thread exits if "set      |scheduler-locking, thread
                   |scheduler-locking on"       |exits and
                   |                            |TARGET_WAITKIND_NO_RESUMED

-- 
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 threads/14618] gdbserver, scheduler-locking, thread exits and TARGET_WAITKIND_NO_RESUMED

[palves at redhat dot com]

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

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
The hangs themselves are now fixed on GDBserver mainline.

  https://sourceware.org/ml/gdb-patches/2014-02/msg00826.html

GDBserver's Linux core now knows about TARGET_WAITKIND_NO_RESUMED, but
I've left out adding that to the RSP ("[PATCH 5/5] Add
TARGET_WAITKIND_NO_RESUMED support to the RSP" at
https://sourceware.org/ml/gdb-patches/2014-01/msg00897.html), because I worried
about races in non-stop mode.

Assume N is the new stop reply for TARGET_WAITKIND_NO_RESUMED, like in the
patch above and say, the traffic goes like this:

(no thread was resumed before #1)

GDB sends two steps in a row.

 #1 -> vCont;s:555
 #2 <- OK

(555 exits)

 #3 <- %Stop:N   (no more resumed threads left)

 #4 -> vCont;s:666
 #5 <- OK

And now GDB goes and processes #3, and mistakenly believes no thread is left
running on the target, while in fact, 666 is left running.  Sounds like we need
something else in addition to TARGET_WAITKIND_NO_RESUMED, maybe thread exit
events (active only for stepped threads, by default, for efficiency).

I'll leave this open until this is fully sorted out.

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

[Bug threads/14618] gdbserver, scheduler-locking, thread exits and TARGET_WAITKIND_NO_RESUMED

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Yao Qi <qiyao@sourceware.org>:

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

commit cafda5977a98aef514ff86daca2fa94205bdd34e
Author: Yao Qi <yao.qi@linaro.org>
Date:   Thu Apr 2 13:51:31 2015 +0100

    kfail two tests in no-unwaited-for-left.exp for remote target

    I see these two fails in no-unwaited-for-left.exp in remote testing
    for aarch64-linux target.

    ...
    continue
    Continuing.
    warning: Remote failure reply: E.No unwaited-for children left.

    [Thread 1084] #2 stopped.
    (gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when
thread 2 exits

    ....
    continue
    Continuing.
    warning: Remote failure reply: E.No unwaited-for children left.

    [Thread 1081] #1 stopped.
    (gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the
main thread exits

    I checked the gdb.log on buildbot, and find that these two fails also
    appear on Debian-i686-native-extended-gdbserver and
Fedora-ppc64be-native-gdbserver-m64.
    I recall that they are about local/remote parity, and related RSP is
missing.
    There has been already a PR 14618 about it.  This patch is to kfail them
    on remote target.

    gdb/testsuite:

    2015-04-02  Yao Qi  <yao.qi@linaro.org>

        * gdb.threads/no-unwaited-for-left.exp: Set up kfail if target
        is remote.

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