From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1A2443858421; Thu, 23 Dec 2021 13:17:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A2443858421 From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/28405] arm-none-eabi: internal-error: ptid_t remote_target::select_thread_for_ambiguous_stop_reply(const target_waitstatus*): Assertion `first_resumed_thread != nullptr' failed Date: Thu, 23 Dec 2021 13:17:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 11.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit 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: 11.2 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: Thu, 23 Dec 2021 13:17:47 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28405 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The gdb-11-branch branch has been updated by Andrew Burgess : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D6eccc2c811ad= 292ce3234d2a0cd71b2184ac40eb commit 6eccc2c811ad292ce3234d2a0cd71b2184ac40eb Author: Andrew Burgess Date: Mon Oct 4 15:48:11 2021 +0100 gdb/remote: handle attach when stop packet lacks thread-id Bug PR gdb/28405 reports a regression when using attach with an extended-remote target. In this case the target is not including a thread-id in the stop packet it sends back after the attach. The regression was introduced with this commit: commit 8f66807b98f7634c43149ea62e454ea8f877691d Date: Wed Jan 13 20:26:58 2021 -0500 gdb: better handling of 'S' packets The problem is that when GDB processes the stop packet, it sees that there is no thread-id and so has to "guess" which thread the stop should apply to. In this case the target only has one thread, so really, there's no guessing needed, but GDB still runs through the same process, this shouldn't cause us any problems. However, after the above commit, GDB now expects itself to be more internally consistent, specifically, only a thread that GDB thinks is resumed, can be a candidate for having stopped. It turns out that, when GDB attaches to a process through an extended-remote target, the threads of the process being attached too, are not, initially, marked as resumed. And so, when GDB tries to figure out which thread the stop might apply too, it finds no threads in the processes marked resumed, and so an assert triggers. In extended_remote_target::attach we create a new thread with a call to add_thread_silent, rather than remote_target::remote_add_thread, the reason is that calling the latter will result in a call to 'add_thread' rather than 'add_thread_silent'. However, remote_target::remote_add_thread includes additional actions (i.e. calling remote_thread_info::set_resumed and set_running) which are missing from extended_remote_target::attach. These missing calls are what would serve to mark the new thread as resumed. In this commit I propose that we add an extra parameter to remote_target::remote_add_thread. This new parameter will force the new thread to be added with a call to add_thread_silent. We can now call remote_add_thread from the ::attach method, the extra actions (listed above) will now be performed, and the thread will be left in the correct state. Additionally, in PR gdb/28405, a segfault is reported. This segfault triggers when 'set debug remote 1' is used before trying to reproduce the original assertion failure. The cause of this is in remote_target::select_thread_for_ambiguous_stop_reply, where we do this: remote_debug_printf ("first resumed thread is %s", pid_to_str (first_resumed_thread->ptid).c_str ()= ); remote_debug_printf ("is this guess ambiguous? =3D %d", ambiguous); gdb_assert (first_resumed_thread !=3D nullptr); Notice that when debug printing is on we dereference first_resumed_thread before we assert that the pointer is not nullptr. This is the cause of the segfault, and is resolved by moving the assert before the debug printing code. I've extended an existing test, ext-attach.exp, so that the original test is run multiple times; we run in the original mode, as normal, but also, we now run with different packets disabled in gdbserver. In particular, disabling Tthread would trigger the assertion as it was reported in the original bug. I also run the test in all-stop and non-stop modes now for extra coverage, we also run the tests with target-async enabled, and disabled. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28405 This is a cherry pick of commit b622494ee378fd0a490 with a minor edit in gdb.server/ext-attach.exp to disable some tests that fail due to unrelated bugs. Those unrelated bugs have been fixed in the master branch. gdb/ChangeLog: PR gdb/28405 * remote.c (remote_target::remote_add_thread): Add new silent_p argument, use as needed. (remote_target::remote_notice_new_inferior): Pass additional argument to remote_add_thread. (remote_target::remote_notice_new_inferior): Likewise. (extended_remote_target::attach): Call remote_add_thread instead of add_thred_silent directly. (remote_target::select_thread_for_ambiguous_stop_reply): Move assert earlier, before we use the thing we're asserting is not nullptr. gdb/testsuite/ChangeLog: PR gdb/28405 * gdb.server/ext-attach.exp (run_test): New proc containing all= of the old code for running the core of the test. This proc is th= en called multiple times from the global scope. --=20 You are receiving this mail because: You are on the CC list for the bug.=