[Bug python/23379] New: [8.1->8.2 regression] gdb.python/py-evthreads.exp, with gdbserver

[palves at redhat dot com]

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

Bug ID: 23379
Summary: [8.1->8.2 regression] gdb.python/py-evthreads.exp,
with gdbserver
Product: gdb
Version: unknown
Status: NEW
Severity: normal
Priority: P2
Component: python
Assignee: unassigned at sourceware dot org
Reporter: palves at redhat dot com
Target Milestone: ---

On Fedora 27, with --target_board=native-gdbserver, comparing 8.1 vs 8.2/master
test results, I see this regression:

-PASS: gdb.python/py-evthreads.exp: run to breakpoint 1
-PASS: gdb.python/py-evthreads.exp: reached breakpoint 2
-PASS: gdb.python/py-evthreads.exp: thread 2
-PASS: gdb.python/py-evthreads.exp: reached breakpoint 3
-PASS: gdb.python/py-evthreads.exp: thread 3
-PASS: gdb.python/py-evthreads.exp: continue thread 1
-PASS: gdb.python/py-evthreads.exp: thread 3 was signaled
+FAIL: gdb.python/py-evthreads.exp: run to breakpoint 1 (GDB internal error)
+FAIL: gdb.python/py-evthreads.exp: reached breakpoint 2 (the program is no
longer running)
+FAIL: gdb.python/py-evthreads.exp: thread 2
+FAIL: gdb.python/py-evthreads.exp: reached breakpoint 3 (the program is no
longer running)
+FAIL: gdb.python/py-evthreads.exp: thread 3
+FAIL: gdb.python/py-evthreads.exp: continue thread 1 (the program is no longer
running)
+FAIL: gdb.python/py-evthreads.exp: thread 3 was signaled (timeout)

gdb.log reveals:

src/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion
`tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.python/py-evthreads.exp: run to
breakpoint 1 (GDB internal error)
Resyncing due to internal error.
^Cevent type: exit


Native testing passes cleanly.

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |8.2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <***@sourceware.org>:

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

commit da3c873831707454d45cee6705075b27a1732f09
Author: Pedro Alves <***@redhat.com>
Date: Fri Aug 24 22:13:30 2018 +0100

Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR
gdb/23379)

This commit fixes a 8.1->8.2 regression exposed by
gdb.python/py-evthreads.exp when testing with
--target_board=native-gdbserver.

gdb.log shows:

src/gdb/thread.c:93: internal-error: thread_info* inferior_thread():
Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.python/py-evthreads.exp:
run to breakpoint 1 (GDB internal error)

A backtrace shows (frames #2 and #10 highlighted) that the assertion
fails when GDB is setting up the connection to the remote target, in
non-stop mode:

#0 0x0000000000622ff0 in internal_error(char const*, int, char const*,
...) (file=0xc1ad98 "src/gdb/thread.c", line=93, fmt=0xc1ad20 "%s: Assertion
`%s' failed.") at src/gdb/common/errors.c:54
#1 0x000000000089567e in inferior_thread() () at src/gdb/thread.c:93
= #2 0x00000000004da91d in get_event_thread() () at
src/gdb/python/py-threadevent.c:38
#3 0x00000000004da9b7 in create_thread_event_object(_typeobject*,
_object*) (py_type=0x11574c0 <continue_event_object_type>, thread=0x0)
at src/gdb/python/py-threadevent.c:60
#4 0x00000000004bf6fe in create_continue_event_object() () at
src/gdb/python/py-continueevent.c:27
#5 0x00000000004bf738 in emit_continue_event(ptid_t) (ptid=...) at
src/gdb/python/py-continueevent.c:40
#6 0x00000000004c7d47 in python_on_resume(ptid_t) (ptid=...) at
src/gdb/python/py-inferior.c:108
#7 0x0000000000485bfb in std::_Function_handler<void (ptid_t), void
(*)(ptid_t)>::_M_invoke(std::_Any_data const&, ptid_t&&) (__functor=...,
__args#0=...) at /usr/include/c++/7/bits/std_function.h:316
#8 0x000000000089b416 in std::function<void
(ptid_t)>::operator()(ptid_t) const (this=0x12aa600, __args#0=...)
at /usr/include/c++/7/bits/std_function.h:706
#9 0x000000000089aa0e in
gdb::observers::observable<ptid_t>::notify(ptid_t) const (this=0x118a7a0
<gdb::observers::target_resumed>, args#0=...)
at src/gdb/common/observable.h:106
= #10 0x0000000000896fbe in set_running(ptid_t, int) (ptid=..., running=1)
at src/gdb/thread.c:880
#11 0x00000000007f750f in remote_target::remote_add_thread(ptid_t, bool,
bool) (this=0x12c5440, ptid=..., running=true, executing=true) at
src/gdb/remote.c:2434
#12 0x00000000007f779d in
remote_target::remote_notice_new_inferior(ptid_t, int) (this=0x12c5440,
currthread=..., executing=1)
at src/gdb/remote.c:2515
#13 0x00000000007f9c44 in remote_target::update_thread_list()
(this=0x12c5440) at src/gdb/remote.c:3831
#14 0x00000000007fb922 in remote_target::start_remote(int, int)
(this=0x12c5440, from_tty=0, extended_p=0)
at src/gdb/remote.c:4655
#15 0x00000000007fd102 in remote_target::open_1(char const*, int, int)
(name=0x1a4f45e "localhost:2346", from_tty=0, extended_p=0)
at src/gdb/remote.c:5638
#16 0x00000000007fbec1 in remote_target::open(char const*, int)
(name=0x1a4f45e "localhost:2346", from_tty=0)
at src/gdb/remote.c:4862

So on frame #10, we're marking a newly-discovered thread as running,
and that causes the Python API to emit a gdb.ContinueEvent.
gdb.ContinueEvent is a gdb.ThreadEvent, and as such includes the event
thread as the "inferior_thread" attribute. The problem is that when
we get to frame #3/#4, we lost all references to the thread that is
being marked as running. create_continue_event_object assumes that it
is the current thread, which is not true in this case.

Fix this by passing down the right thread in
create_continue_event_object. Also remove
create_thread_event_object's default argument and have the only other
caller left pass down the right thread explicitly too.

gdb/ChangeLog:
2018-08-24 Pedro Alves <***@redhat.com>
Simon Marchi <***@ericsson.com>

PR gdb/23379
* python/py-continueevent.c: Include "gdbthread.h".
(create_continue_event_object): Add intro comment. Add 'ptid'
parameter. Use it to find thread to pass to
create_thread_event_object.
(emit_continue_event): Pass PTID down to
create_continue_event_object.
* python/py-event.h (py_get_event_thread): Declare.
(create_thread_event_object): Remove default from 'thread'
parameter.
* python/py-stopevent.c (create_stop_event_object): Use
py_get_event_thread.
* python/py-threadevent.c (get_event_thread): Rename to ...
(py_get_event_thread): ... this, make extern, add 'ptid' parameter
and use it to find the thread.
(create_thread_event_object): Assert that THREAD isn't null.
Don't find the event thread here.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-8.2-branch branch has been updated by Pedro Alves
<***@sourceware.org>:

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

commit 0e84db8c75a5afbfef02a295f4f8867bd07ea12d
Author: Pedro Alves <***@redhat.com>
Date: Fri Aug 24 22:24:49 2018 +0100

Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR
gdb/23379)

This commit fixes a 8.1->8.2 regression exposed by
gdb.python/py-evthreads.exp when testing with
--target_board=native-gdbserver.

gdb.log shows:

src/gdb/thread.c:93: internal-error: thread_info* inferior_thread():
Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.python/py-evthreads.exp:
run to breakpoint 1 (GDB internal error)

A backtrace shows (frames #2 and #10 highlighted) that the assertion
fails when GDB is setting up the connection to the remote target, in
non-stop mode:

#0 0x0000000000622ff0 in internal_error(char const*, int, char const*,
...) (file=0xc1ad98 "src/gdb/thread.c", line=93, fmt=0xc1ad20 "%s: Assertion
`%s' failed.") at src/gdb/common/errors.c:54
#1 0x000000000089567e in inferior_thread() () at src/gdb/thread.c:93
= #2 0x00000000004da91d in get_event_thread() () at
src/gdb/python/py-threadevent.c:38
#3 0x00000000004da9b7 in create_thread_event_object(_typeobject*,
_object*) (py_type=0x11574c0 <continue_event_object_type>, thread=0x0)
at src/gdb/python/py-threadevent.c:60
#4 0x00000000004bf6fe in create_continue_event_object() () at
src/gdb/python/py-continueevent.c:27
#5 0x00000000004bf738 in emit_continue_event(ptid_t) (ptid=...) at
src/gdb/python/py-continueevent.c:40
#6 0x00000000004c7d47 in python_on_resume(ptid_t) (ptid=...) at
src/gdb/python/py-inferior.c:108
#7 0x0000000000485bfb in std::_Function_handler<void (ptid_t), void
(*)(ptid_t)>::_M_invoke(std::_Any_data const&, ptid_t&&) (__functor=...,
__args#0=...) at /usr/include/c++/7/bits/std_function.h:316
#8 0x000000000089b416 in std::function<void
(ptid_t)>::operator()(ptid_t) const (this=0x12aa600, __args#0=...)
at /usr/include/c++/7/bits/std_function.h:706
#9 0x000000000089aa0e in
gdb::observers::observable<ptid_t>::notify(ptid_t) const (this=0x118a7a0
<gdb::observers::target_resumed>, args#0=...)
at src/gdb/common/observable.h:106
= #10 0x0000000000896fbe in set_running(ptid_t, int) (ptid=..., running=1)
at src/gdb/thread.c:880
#11 0x00000000007f750f in remote_target::remote_add_thread(ptid_t, bool,
bool) (this=0x12c5440, ptid=..., running=true, executing=true) at
src/gdb/remote.c:2434
#12 0x00000000007f779d in
remote_target::remote_notice_new_inferior(ptid_t, int) (this=0x12c5440,
currthread=..., executing=1)
at src/gdb/remote.c:2515
#13 0x00000000007f9c44 in remote_target::update_thread_list()
(this=0x12c5440) at src/gdb/remote.c:3831
#14 0x00000000007fb922 in remote_target::start_remote(int, int)
(this=0x12c5440, from_tty=0, extended_p=0)
at src/gdb/remote.c:4655
#15 0x00000000007fd102 in remote_target::open_1(char const*, int, int)
(name=0x1a4f45e "localhost:2346", from_tty=0, extended_p=0)
at src/gdb/remote.c:5638
#16 0x00000000007fbec1 in remote_target::open(char const*, int)
(name=0x1a4f45e "localhost:2346", from_tty=0)
at src/gdb/remote.c:4862

So on frame #10, we're marking a newly-discovered thread as running,
and that causes the Python API to emit a gdb.ContinueEvent.
gdb.ContinueEvent is a gdb.ThreadEvent, and as such includes the event
thread as the "inferior_thread" attribute. The problem is that when
we get to frame #3/#4, we lost all references to the thread that is
being marked as running. create_continue_event_object assumes that it
is the current thread, which is not true in this case.

Fix this by passing down the right thread in
create_continue_event_object. Also remove
create_thread_event_object's default argument and have the only other
caller left pass down the right thread explicitly too.

gdb/ChangeLog:
2018-08-24 Pedro Alves <***@redhat.com>
Simon Marchi <***@ericsson.com>

PR gdb/23379
* python/py-continueevent.c: Include "gdbthread.h".
(create_continue_event_object): Add intro comment. Add 'ptid'
parameter. Use it to find thread to pass to
create_thread_event_object.
(emit_continue_event): Pass PTID down to
create_continue_event_object.
* python/py-event.h (py_get_event_thread): Declare.
(create_thread_event_object): Remove default from 'thread'
parameter.
* python/py-stopevent.c (create_stop_event_object): Use
py_get_event_thread.
* python/py-threadevent.c (get_event_thread): Rename to ...
(py_get_event_thread): ... this, make extern, add 'ptid' parameter
and use it to find the thread.
(create_thread_event_object): Assert that THREAD isn't null.
Don't find the event thread here.

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Version|unknown |8.2
Resolution|--- |FIXED

--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Fixed.