[PATCH v2][PR 30630] gdb/remote: fix assertion failure during startup
Andrew Burgess
aburgess@redhat.com
Tue Jul 30 09:31:36 GMT 2024
Trung Nguyen <me@trungnt2910.com> writes:
> Ensure that calls to `remote_state::mark_async_event_handler` are only
> made when the target is in async mode:
> - Replace the check for `target_can_async_p` in
> `remote_target::queued_stop_reply` with `target_is_async_p`.
> - Add a check in `remote_notif_stop_can_get_pending_events`.
>
> During early startup, `process_initial_stop_replies` was called before
> asynchronous mode was enabled. The function then called
> `remote_target::queued_stop_reply`, which then tried to mark the event
> handler on all targets claiming async support, regardless of whether
> async mode had been enabled or not. This triggered an assertion fail if
> there had been queued stop replies.
>
> The bug can be reproduced when running in non-stop mode while connected
> to a custom build of `gdbserver`. This build always returns an extra
> library stop notification due to the system libraries loading extra
> add-ons right after program startup.
I'm helping on a project which aims to improve remote protocol testing.
It's not ready for posting / merging yet, but I do have an interest in
bugs like this which might be hard to test using the existing in-tree
gdbserver. I mention this to explain why I'm asking...
... what's a "library stop notification"?
I think what might be going on is that GDB receives this packet:
[remote] Notification received: Stop:T0006:20310801007f0000;07:a8300801007f0000;10:a13c110000000000;thread:p85a.0;library:;
while it's processing the thread list, which is pushed as a pending
stop, but (as you explained) this is before we've switched to async
mode, so when we call remote_target::process_initial_stop_replies, which
calls target_wait we end up throwing the assertion. Is this correct?
My observations with the in-tree gdbserver is that it seems to hold off
sending a stop reply until after the initial '?' packet has been sent,
though I haven't looked at the code to see if this is deliberate, or
just that gdbserver hasn't gotten around to it yet. My reading of the
docs is that what your stub is doing is fine, and I agree with your fix,
I'd just like to confirm my understanding of the bug here.
Thanks,
Andrew
>
> gdb/gdb -ex "set non-stop on" -ex "set debug remote 1" \
> -ex "target remote $VM_HOST:6666"
>
> Remote debugging using 192.168.154.176:6666
> [remote] start_remote_1: enter
> [remote] Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;QThreadOptions+;no-resumed+;memory-tagging+;xmlRegisters=i386#72
> [remote] Received Ack
> [remote] Packet received: PacketSize=2001f;QPassSignals+;QProgramSignals+;QStartupWithShell+;QEnvironmentHexEncoded+;QEnvironmentReset+;QEnvironmentUnset+;QSetWorkingDir+;QCatchSyscalls+;qXfer:libraries:read+;qXfer:features:read+;QStartNoAckMode+;qXfer:osdata:read+;multiprocess+;fork-events+;exec-events+;QNonStop+;QDisableRandomization+;qXfer:threads:read+;BreakpointCommands+;qXfer:exec-file:read+;vContSupported+;QThreadEvents+;no-resumed+
> [remote] packet_ok: Packet qSupported (supported-packets) is supported
> [remote] Sending packet: $vCont?#49
> [remote] Received Ack
> [remote] Packet received: vCont;c;C;t
> [remote] packet_ok: Packet vCont (verbose-resume) is supported
> [remote] Sending packet: $vMustReplyEmpty#3a
> [remote] Received Ack
> [remote] Packet received:
> [remote] Sending packet: $QStartNoAckMode#b0
> [remote] Received Ack
> [remote] Packet received: OK
>
> [remote] Sending packet: $QNonStop:1#8d
> [remote] Packet received: OK
> [remote] Sending packet: $qXfer:threads:read::0,1000#92
> [remote] Notification received: Stop:T0006:20310801007f0000;07:a8300801007f0000;10:a13c110000000000;thread:p85a.0;library:;
> [remote] Packet received: l<threads>\n<thread id="p85a.0" name="cat"/>\n</threads>\n
> [remote] Sending packet: $vStopped#55
> [remote] Packet received: OK
> [remote] Sending packet: $qAttached:85a#97
> [remote] Packet received: 0
> [remote] packet_ok: Packet qAttached (query-attached) is supported
> [remote] Sending packet: $qXfer:exec-file:read:85a:0,1000#e7
> [remote] Packet received: l/boot/system/bin/cat
> [remote] Sending packet: $vFile:setfs:0#bf
> [remote] Packet received:
> [remote] packet_ok: Packet vFile:setfs (hostio-setfs) is NOT supported
> [remote] Sending packet: $vFile:open:6a7573742070726f62696e67,0,1c0#ed
> [remote] Packet received: F-1,2
> [remote] packet_ok: Packet vFile:open (hostio-open) is supported
> Reading /boot/system/bin/cat from remote target...
> warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
>
> [remote] Sending packet: $QPassSignals:#f3
> [remote] Packet received: OK
> [remote] wait: enter
> ../../gdb-haiku/gdb/remote.c:504: internal-error: mark_async_event_handler: Assertion `this->is_async_p ()' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> ----- Backtrace -----
> 0x7f6328d6b0b5 gdb_internal_backtrace_1
> ../../gdb-haiku/gdb/bt-utils.c:121
> 0x7f6328d6b0b5 _Z22gdb_internal_backtracev
> ../../gdb-haiku/gdb/bt-utils.c:167
> 0x7f6329145214 internal_vproblem
> ../../gdb-haiku/gdb/utils.c:420
> 0x7f6329145540 _Z15internal_verrorPKciS0_P13__va_list_tag
> ../../gdb-haiku/gdb/utils.c:500
> 0x7f632929ecc4 _Z18internal_error_locPKciS0_z
> ../../gdb-haiku/gdbsupport/errors.cc:57
> 0x7f632902f48d _ZN12remote_state24mark_async_event_handlerEv
> ../../gdb-haiku/gdb/remote.c:504
> 0x7f63290375d4 _ZN12remote_state24mark_async_event_handlerEv
> ../../gdb-haiku/gdb/remote.c:7912
> 0x7f63290375d4 _ZN13remote_target17queued_stop_replyE6ptid_t
> ../../gdb-haiku/gdb/remote.c:7908
> 0x7f6329042b21 _ZN13remote_target7wait_nsE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
> ../../gdb-haiku/gdb/remote.c:8602
> 0x7f6329043466 _ZN13remote_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
> ../../gdb-haiku/gdb/remote.c:8804
> 0x7f63290f1c45 _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
> ../../gdb-haiku/gdb/target.c:2579
> 0x7f63290460bb _ZN13remote_target28process_initial_stop_repliesEi
> ../../gdb-haiku/gdb/remote.c:4906
> 0x7f632904c847 _ZN13remote_target14start_remote_1Eii
> ../../gdb-haiku/gdb/remote.c:5365
> 0x7f632904ce3c _ZN13remote_target12start_remoteEii
> ../../gdb-haiku/gdb/remote.c:5417
> 0x7f632904ce3c _ZN13remote_target6open_1EPKcii
> ../../gdb-haiku/gdb/remote.c:6279
> 0x7f63290f2ba8 open_target
> ../../gdb-haiku/gdb/target.c:837
> 0x7f6328d9f9b4 _Z8cmd_funcP16cmd_list_elementPKci
> ../../gdb-haiku/gdb/cli/cli-decode.c:2741
> 0x7f6329102e64 _Z15execute_commandPKci
> ---
> gdb/remote.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/remote.c b/gdb/remote.c
> index 4948a54e322..c6f05c4af30 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -7710,8 +7710,11 @@ remote_notif_stop_can_get_pending_events (remote_target *remote,
> instead. If we fetch all queued events from stub, remote stub
> may exit and we have no chance to process them back in
> remote_wait_ns. */
> - remote_state *rs = remote->get_remote_state ();
> - rs->mark_async_event_handler ();
> + if (target_is_async_p ())
> + {
> + remote_state *rs = remote->get_remote_state ();
> + rs->mark_async_event_handler ();
> + }
> return 0;
> }
>
> @@ -7908,7 +7911,7 @@ remote_target::queued_stop_reply (ptid_t ptid)
> remote_state *rs = get_remote_state ();
> stop_reply_up r = remote_notif_remove_queued_reply (ptid);
>
> - if (!rs->stop_reply_queue.empty () && target_can_async_p ())
> + if (!rs->stop_reply_queue.empty () && target_is_async_p ())
> {
> /* There's still at least an event left. */
> rs->mark_async_event_handler ();
> --
> 2.39.1.windows.1
More information about the Gdb-patches
mailing list