From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9604E3836C2C; Mon, 30 Nov 2020 10:32:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9604E3836C2C From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug remote/26614] AddressSanitizer: heap-use-after-free of extended_remote_target in remote_async_inferior_event_handler Date: Mon, 30 Nov 2020 10:32:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: remote X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 10:32:08 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26614 --- Comment #14 from Tom de Vries --- (In reply to Simon Marchi from comment #12) > It looks very similar to a problem I hit while doing some unrelated chang= es. > I think the reason is: >=20 > static void > remote_async_inferior_event_handler (gdb_client_data data) > { > inferior_event_handler (INF_REG_EVENT); <--- remote target can get > destroyed anywhere here >=20 > remote_target *remote =3D (remote_target *) data; > remote_state *rs =3D remote->get_remote_state (); <--- we dereference = the > remote target here >=20 > /* inferior_event_handler may have consumed an event pending on the > infrun side without calling target_wait on the REMOTE target, or > may have pulled an event out of a different target. Keep trying > for this remote target as long it still has either pending events > or unacknowledged notifications. */ >=20 > if (rs->notif_state->pending_event[notif_client_stop.id] !=3D NULL > || !rs->stop_reply_queue.empty ()) > mark_async_event_handler (rs->remote_async_inferior_event_token); > } >=20 >=20 > inferior_event_target can lead to the remote target to be destroyed. An > "exit" stop reply from the target can lead to it, but communication failu= re > is another one. >=20 Agreed, it's the same problem. Thanks for helping me out here. > The reason why it is difficult to reproduce is that inferior_event_handler > is also called from remote_async_serial_handler, which doesn't have the s= ame > code that dereferences the remote target. So the bug can only trigger wh= en > inferior_event_handler is called through > remote_async_inferior_event_handler, which likely happens less often than > being called through remote_async_serial_handler. >=20 I see. > I did write this patch below to make it so inferior_event_handler is alwa= ys > called through remote_async_inferior_event_handler, that automatically > triggers the bug in the simplest cases (the inferior exits with "target > remote"). It makes it so remote_async_serial_handler doesn't call > remote_async_inferior_event_handler anymore, but just marks the remote > target's async handler. >=20 Yep, works for me to trigger the problem. Using this patch, I trigger the original failure with -m32: ... Running src/gdb/testsuite/gdb.multi/multi-target-continue.exp ... ERROR: GDB process no longer exists ... and this one with -m64: ... Running src/gdb/testsuite/gdb.multi/multi-target-no-resumed.exp ... ERROR: GDB process no longer exists ... when running gdb.multi/*.exp. > What I like from this patch is that there's now a single path from the > remote target to inferior_event_handler, so less variations to consider, > more determinism. Agreed, that's a good thing :) --=20 You are receiving this mail because: You are on the CC list for the bug.=