This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: skip_inline_frames failed assertion resuming from breakpoint on LynxOS
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Thu, 20 Nov 2014 09:55:43 +0000
- Subject: Re: RFC: skip_inline_frames failed assertion resuming from breakpoint on LynxOS
- Authentication-results: sourceware.org; auth=none
- References: <20141120051109 dot GR5774 at adacore dot com> <20141120051223 dot GA23720 at adacore dot com>
On 11/20/2014 05:12 AM, Joel Brobecker wrote:
>> > I am still trying to reproduce the problem locally in order to
>> > find out more, but I couldn't understand why, in principle,
>> > one thread couldn't receive multiple notifications during
>> > the same single-step if the system decides to queue up signals?
>> > If that were the case, wouldn't the attached patch make sense?
>> > (currently untested against the program that triggered the issue,
>> > as I think I understand how inline-frame works, and what it does,
>> > but I am not sure I get it all).
> Thanks again!
> -- Joel
>
>
> 0001-skip_inline_frames-failed-assertion-resuming-from-br.patch
>
>
> From f7ad35aa92a7007194582b1e23a110fc06b50cd1 Mon Sep 17 00:00:00 2001
> From: Joel Brobecker <brobecker@adacore.com>
> Date: Thu, 20 Nov 2014 08:38:08 +0400
> Subject: [PATCH] skip_inline_frames failed assertion resuming from breakpoint
> on LynxOS
>
> A user reported a failed assertion while debugging their program
> on a LynxOS system (thus via GDBserver), when trying to resume
> the program's execution after having reached a breakpoint:
>
> (gdb) continue
> [...]
> ../../src/gdb/inline-frame.c:339: internal-error: skip_inline_frames: Assertion `find_inline_frame_state (ptid) == NULL' failed.
>
> Turning infrun debug traces helps understand a little better what
> happens:
>
> (gdb) continue
> Continuing.
> infrun: clear_proceed_status_thread (Thread 126)
> [...]
> infrun: clear_proceed_status_thread (Thread 142)
> [...]
> infrun: clear_proceed_status_thread (Thread 146)
> infrun: clear_proceed_status_thread (Thread 125)
> infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=0)
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838
trap_expected=1 indicates that GDB is about to step thread 142 _only_, leaving
everything else stopped. Can you enable "set debug remote 1" as well?
> infrun: wait_for_inferior ()
> infrun: target_wait (-1, status) =
> infrun: 42000 [Thread 146],
> infrun: status->kind = stopped, signal = GDB_SIGNAL_REALTIME_34
So how come we see an event for thread 146? That thread shouldn't
have been resumed, so GDB shouldn't be getting an event for it.
This is sounding like a bug in the target.
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x10a187f4
> infrun: context switch
> infrun: Switching context from Thread 142 to Thread 146
> infrun: random signal (GDB_SIGNAL_REALTIME_34)
> infrun: switching back to stepped thread
> infrun: Switching context from Thread 146 to Thread 142
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838
> infrun: prepare_to_wait
> [...handling of similar events for threads 145, 144 and 143 snipped...]
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) =
> infrun: 42000 [Thread 146],
> infrun: status->kind = stopped, signal = GDB_SIGNAL_REALTIME_34
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x10a187f4
> infrun: context switch
> infrun: Switching context from Thread 142 to Thread 146
> ../../src/gdb/inline-frame.c:339: internal-error: skip_inline_frames: Assertion `find_inline_frame_state (ptid) == NULL' failed.
Thanks,
Pedro Alves