These fails are mentioned here http://sourceware.org/ml/gdb-patches/2012-05/msg00290.html. Track them in this PR. Run test suite with async mode, then we can see following fails. FAIL: gdb.python/py-finish-breakpoint.exp: check MyFinishBreakpoint hit (GDB internal error) FAIL: gdb.python/py-finish-breakpoint.exp: check stopped location FAIL: gdb.python/py-finish-breakpoint.exp: stop in condition function FAIL: gdb.python/py-finish-breakpoint.exp: stop at conditional breakpoint Noe that this test case fails (in async mode) when it was introduced by this commit 7c56fb07bde331d79eb73ece26b8fc960aa13eb2.
I took a look at this bug, but the python code **seems** not to be directly involved. The internal error comes from infrun.c:5973 if (last.kind == TARGET_WAITKIND_NO_RESUMED) { gdb_assert (sync_execution || !target_can_async_p ()); target_terminal_ours_for_output (); printf_filtered (_("No unwaited-for children left.\n")); } and it seems to be related to these messages linux_nat_wait: [process -1] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (no resumed LWP) No unwaited-for children left. coming from linux-nat.c:3689 (linux_nat_wait_1) ... but I have no clue what to do next ... Let me know of you have any idea / if there is something I can do
(In reply to comment #1) > I took a look at this bug, but the python code **seems** not to be directly > involved. > > The internal error comes from infrun.c:5973 > > if (last.kind == TARGET_WAITKIND_NO_RESUMED) > { > gdb_assert (sync_execution || !target_can_async_p ()); > > target_terminal_ours_for_output (); > printf_filtered (_("No unwaited-for children left.\n")); > } > > and it seems to be related to these messages > > linux_nat_wait: [process -1] > LLW: enter > LNW: waitpid(-1, ...) returned 0, No child processes > LLW: exit (no resumed LWP) > No unwaited-for children left. > > coming from linux-nat.c:3689 (linux_nat_wait_1) ... but I have no clue what to > do next ... > > > Let me know of you have any idea / if there is something I can do The python code is involved in this way, as this backtrace displayed, (gdb) bt #0 linux_nat_wait_1 (ops=0x84a2b58, ptid=..., ourstatus=0xbfffe3e4, target_options=<value optimized out>) at ../../gdb/gdb/linux-nat.c:3821 #1 linux_nat_wait (ops=0x84a2b58, ptid=..., ourstatus=0xbfffe3e4, target_options=<value optimized out>) at ../../gdb/gdb/linux-nat.c:4074 #2 0x081ec68b in target_wait (ptid=..., status=0xbfffe3e4, options=1) at ../../gdb/gdb/target.c:2624 #3 0x081bae60 in fetch_inferior_event (client_data=0x0) at ../../gdb/gdb/infrun.c:2789 #4 0x081cffa1 in fetch_inferior_event_wrapper (client_data=0x0) at ../../gdb/gdb/inf-loop.c:145 #5 0x081c68cb in catch_errors (func=0x81cff90 <fetch_inferior_event_wrapper>, func_args=0x0, errstring=0x8365d81 "", mask=6) at ../../gdb/gdb/exceptions.c:546 #6 0x081cfcf3 in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at ../../gdb/gdb/inf-loop.c:53 #7 0x081ce4c2 in handle_file_event (data=...) at ../../gdb/gdb/event-loop.c:827 #8 0x081cdb3b in process_event () at ../../gdb/gdb/event-loop.c:401 #9 0x081ce9d6 in gdb_do_one_event () at ../../gdb/gdb/event-loop.c:453 #10 0x08283497 in execute_command (p=0x85beb0e "1", from_tty=0) at ../../gdb/gdb/top.c:492 #11 0x08113354 in execute_gdb_command (self=0x0, args=0x856240c, kw=0x0) at ../../gdb/gdb/python/python.c:453 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #12 0x0021dca8 in PyCFunction_Call () from /usr/lib/libpython2.6.so.1.0 #13 0x0027e45e in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #14 0x0027fcbd in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #15 0x00207e97 in ?? () from /usr/lib/libpython2.6.so.1.0 #16 0x001d8edc in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #17 0x001eae34 in ?? () from /usr/lib/libpython2.6.so.1.0 #18 0x001d8edc in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #19 0x001de19e in _PyObject_CallMethod_SizeT () from /usr/lib/libpython2.6.so.1.0 #20 0x08116f20 in gdbpy_should_stop (bp_obj=0x3a6ff4) at ../../gdb/gdb/python/py-breakpoint.c:735 #21 0x08161b4a in bpstat_check_breakpoint_conditions (aspace=0x8547730, bp_addr=134514268, ptid=..., ws=0xbfffeef4) at ../../gdb/gdb/breakpoint.c:4713 #22 bpstat_stop_status (aspace=0x8547730, bp_addr=134514268, ptid=..., ws=0xbfffeef4) at ../../gdb/gdb/breakpoint.c:4938 #23 0x081b8b88 in handle_inferior_event (ecs=0xbfffeee4) at ../../gdb/gdb/infrun.c:4227 #24 0x081babb9 in fetch_inferior_event (client_data=0x0) at ../../gdb/gdb/infrun.c:2817 #25 0x081cffa1 in fetch_inferior_event_wrapper (client_data=0x0) at ../../gdb/gdb/inf-loop.c:145 #26 0x081c68cb in catch_errors (func=0x81cff90 <fetch_inferior_event_wrapper>, func_args=0x0, errstring=0x8365d81 "", mask=6) at ../../gdb/gdb/exceptions.c:546 #27 0x081cfcf3 in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at ../../gdb/gdb/inf-loop.c:53 #28 0x081ce4c2 in handle_file_event (data=...) at ../../gdb/gdb/event-loop.c:827 #29 0x081cdb3b in process_event () at ../../gdb/gdb/event-loop.c:401 #30 0x081ce9d6 in gdb_do_one_event () at ../../gdb/gdb/event-loop.c:453 #31 0x08283497 in execute_command (p=0xbffff5f5 "", from_tty=1) at ../../gdb/gdb/top.c:492 #32 0x081c683a in catch_command_errors (command=0x8283330 <execute_command>, arg=0xbffff5f4 "c", from_tty=1, mask=6) at ../../gdb/gdb/exceptions.c:573 #33 0x081c8b20 in captured_main (data=0xbffff230) at ../../gdb/gdb/main.c:977 #34 0x081c68cb in catch_errors (func=0x81c8090 <captured_main>, func_args=0xbffff230, errstring=0x8365d81 "", mask=6) at ../../gdb/gdb/exceptions.c:546 #35 0x081c7de2 in gdb_main (args=0xbffff230) at ../../gdb/gdb/main.c:1010 #36 0x08094cf3 in main (argc=20, argv=0xbffff2f4) at ../../gdb/gdb/gdb.c:34 In frame #11, we can see that it tries to execute a command, in gdb.python/py-finish-breakpoint.py, we can see a command "where 1" is used in MyFinishBreakpoint::stop(self) [1], class MyFinishBreakpoint (gdb.FinishBreakpoint): def __init__(self, val, frame): gdb.FinishBreakpoint.__init__ (self, frame) print "MyFinishBreakpoint init" self.val = val def stop(self): print "MyFinishBreakpoint stop with %d" % int (self.val.dereference ()) print "return_value is: %d" % int (self.return_value) gdb.execute ("where 1") // <-------- [1] return True def out_of_scope(self): print "MyFinishBreakpoint out of scope" If remove this line [1], internal error goes away. The doc says "23.2.2.20 Manipulating breakpoints using Python. ... You should not alter the execution state of the inferior (i.e., step, next, etc.), alter the current frame context (i.e., change the current active frame), or alter, add or delete any breakpoint. As a general rule, you should not alter any data within gdb or the inferior at this time.". I doubt "where 1" falls in this category in async mode.
you're right indeed, I did not notice this part of the execution. > The doc says "23.2.2.20 Manipulating breakpoints using Python. ... You should > not alter the execution state of the inferior (i.e., step, next, etc.), alter > the current frame context (i.e., change the current active frame), or alter, > add or delete any breakpoint. As a general rule, you should not alter any data > within gdb or the inferior at this time.". > I doubt "where 1" falls in this category in async mode. I'm not sure to understand your position here: would you like me to change appropriately "gdb.execute ("where 1")" and fix the testsuite failure, or will you guys try to fix the underlying problem ?
(In reply to comment #3) > > I'm not sure to understand your position here: would you like me to change > appropriately "gdb.execute ("where 1")" and fix the testsuite failure, or will > you guys try to fix the underlying problem ? I am not sure on this either :) It is good if we can fix the underlying problem, but don't know how much work it needs. At the same time, I'd like to remove "gdb.execute ("where 1")" from test case. I am not familiar with gdb/python, but the `stop' method is similar to breakpoint condition, and I feel it is not right to put gdb.execute (which is similar to breakpoint action) to it. Anyway, I'll post a patch to @gdb-patches to see how people there think on this.
Patches are posted http://sourceware.org/ml/gdb-patches/2012-05/msg00963.html
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 90e289504f844c162ab2e701f99a309d2b37a62a (commit) from beb460e8d2ddf5327a6ab146055a6e6e9f552a4b (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=90e289504f844c162ab2e701f99a309d2b37a62a commit 90e289504f844c162ab2e701f99a309d2b37a62a Author: Tom Tromey <tromey@redhat.com> Date: Tue Mar 4 11:32:52 2014 -0700 Fix py-finish-breakpoint.exp with target async. With target async enabled, py-finish-breakpoint.exp triggers an assertion failure. The failure occurs because execute_command re-enters the event loop in some circumstances, and in this case resets the sync_execution flag. Then later GDB reaches this assertion in normal_stop: gdb_assert (sync_execution || !target_can_async_p ()); In detail: #1 - A synchronous execution command is run. sync_execution is set. #2 - A python breakpoint is hit (TARGET_WAITKIND_STOPPED), and the corresponding Python breakpoint's stop method is executed. When and while python commands are executed, interpreter_async is forced to 0. #3 - The Python stop method happens to execute a not-execution-related gdb command. In this case, "where 1". #4 - Seeing that sync_execution is set, execute_command nests a new event loop (although that wasn't necessary; this is the problem). #5 - The linux-nat target's pipe in the event loop happens to be marked. That's normal, due to this in linux_nat_wait: /* If we requested any event, and something came out, assume there may be more. If we requested a specific lwp or process, also assume there may be more. */ The nested event loop thus immediately wakes up and calls target_wait. No thread is actually executing in the inferior, so the target returns TARGET_WAITKIND_NO_RESUMED. #6 - normal_stop is reached. GDB prints "No unwaited-for children left.", and resets the sync_execution flag (IOW, there are no resumed threads left, so the synchronous command is considered completed.) This is already bogus. We were handling a breakpoint! #7 - the nested event loop unwinds/ends. GDB is now back to handling the python stop method (TARGET_WAITKIND_STOPPED), which decides the breakpoint should stop. normal_stop is called for this event. However, normal_stop actually works with the _last_ reported target status: void normal_stop (void) { struct target_waitstatus last; ptid_t last_ptid; struct cleanup *old_chain = make_cleanup (null_cleanup, NULL); ... get_last_target_status (&last_ptid, &last); ... if (last.kind == TARGET_WAITKIND_NO_RESUMED) { gdb_assert (sync_execution || !target_can_async_p ()); target_terminal_ours_for_output (); printf_filtered (_("No unwaited-for children left.\n")); } And due to the nesting in execute command, the last event is now TARGET_WAITKIND_NO_RESUMED, not the actual breakpoint event being handled. This could be seen to be broken in itself, but we can leave fixing that for another pass. The assertion is reached, and fails. execute_command has a comment explaining when it should synchronously wait for events: /* If the interpreter is in sync mode (we're running a user command's list, running command hooks or similars), and we just ran a synchronous command that started the target, wait for that command to end. */ However, the code did not follow this comment -- it didn't check to see if the command actually started the target, just whether the target was executing a sync command at this point. This patch fixes the problem by noting whether the target was executing in sync_execution mode before running the command, and then augmenting the condition to test this as well. 2014-03-20 Tom Tromey <tromey@redhat.com> PR gdb/14135 * top.c (execute_command): Only dispatch events if the command started the target. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 6 ++++++ gdb/top.c | 4 +++- 2 files changed, 9 insertions(+), 1 deletions(-)
Fixed.