[Bug breakpoints/21497] New: FreeBSD: infrun.c:5565: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed

["jlott1 at yahoo dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 21497
           Summary: FreeBSD: infrun.c:5565: internal-error: int
                    finish_step_over(execution_control_state*): Assertion
                    `ecs->event_thread->control.trap_expected' failed
           Product: gdb
           Version: 7.12.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: jlott1 at yahoo dot com
                CC: jhb at FreeBSD dot org
  Target Milestone: ---

Created attachment 10053
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10053&action=edit
Debug log of the failed continue

I'm using gdb7121 from FreeBSD ports. Getting this assert occasionally when
continuing from a breakpoint:

infrun.c:5565: internal-error: int finish_step_over(execution_control_state*):
Assertion `ecs->event_thread->control.trap_expected' failed.

I ran with some debugging on to narrow it down (set debug target 1; set debug
infrun 1; set debug fbsd-lwp 1). Unfortunately it takes a long time to
reproduce so the debug output is fairly large (30MB). Only the end is really
relevant, I think. It appears to be an interaction (race condition) between new
threads being launched and the continuing of a thread from a breakpoint.

Skipping over a lot of the verbose messages for brevity/clarity, you can see
the sequence in the last continue:

-> native->to_log_command (...)
<- native->to_log_command (0x1d7f300, c)
Continuing.
...
infrun: resuming [LWP 102181 of process 23510] for step-over
...
infrun: skipping breakpoint: stepping past insn at: 0x1df0c07
infrun: skipping breakpoint: stepping past insn at: 0x1df0c07
-> native->to_insert_breakpoint (...)
...
<- native->to_insert_breakpoint (0x1d7f300, i386:x86-64, 0x000000080a335d00) =
0
...
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread
[LWP 102181 of process 23510] at 0x1df0c07
...
FLWP: fbsd_resume for ptid (23510, 102181, 0)

So far so good, everything is setup to single-step LWP 102181. However, because
it is single stepping, it is expecting to only receive events about that
thread. However, there was already a thread-create event pending when the
breakpoint occurred. Therefore the next event that gets returned from pthread
is actually a create for a different thread.

FLWP: adding thread for LWP 101493
...
[New LWP 101493 of process 23510]
...
infrun: target_wait (-1.0.0, status) =
infrun:   23510.101493.0 [LWP 101493 of process 23510],
infrun:   status->kind = spurious
...
infrun: TARGET_WAITKIND_SPURIOUS
...
infrun: Switching context from LWP 102181 of process 23510 
...
to LWP 101493 of process 23510

After it processes this new thread, it will now resume all threads. This is not
good, because the "continue" code still thinks it is in single-step mode.

infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[LWP 101493 of process 23510] at 0x80add2d20
...
FLWP: fbsd_resume for ptid (-1, 0, 0)

Because all threads are now running, another thread hits the temporary
breakpoint that was intended for the single-stepping thread.

infrun: target_wait (-1.0.0, status) =
infrun:   23510.101602.0 [LWP 101602 of process 23510],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
...
infrun: TARGET_WAITKIND_STOPPED

Now it checks to see that the thread that hit the breakpoint is the correct
thread that was single-stepping. It was not, hence the assert.

infrun.c:5565: internal-error: int finish_step_over(execution_control_state*):
Assertion `ecs->event_thread->control.trap_expected' failed.

I hope this is clear. It seems there is a mismatch between what the "core" gdb
code expects in terms of ptrace event ordering and how the FreeBSD ptrace API
actually behaves. I'll attach the (unfiltered) end of the log to the report as
well. I can reproduce locally with our application relatively easily, but I've
not come up with a standalone test program to cause it yet.

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