public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "andrew.burgess at embecosm dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/27830] New: Attempt to resume already running thread Date: Fri, 07 May 2021 14:16:54 +0000 [thread overview] Message-ID: <bug-27830-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=27830 Bug ID: 27830 Summary: Attempt to resume already running thread Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: andrew.burgess at embecosm dot com Target Milestone: --- Created attachment 13423 --> https://sourceware.org/bugzilla/attachment.cgi?id=13423&action=edit reproducer When using 'target remote', 'set non-stop on' and 'set displaced-stepping off', if we step over an instruction that creates a new thread then GDB ends up trying to resume a thread that is already running. To reproduce, download the attached tar file then: $ tar -xf thr-resume-issue.tar.xz $ cd thr-resume-issue $ make .....snip.... [New Thread 3878916.3878917] cmd.gdb:12: Error in sourced command file: PC register is not available **** FAILED **** This test case is only going to work on an x86-64/Linux setup. Notice the "PC register is not available" error. This is caused by GDB trying to read the $pc from the new running thread. In more detail what happens is that GDB stops at the syscall instruction that will spawn a new thread. At this point the inferior is single threaded. Next we 'stepi', as displaced stepping is off we do inplace stepping. When the step is completed we end up in finish_step_over (infrun.c), this then calls restart_threads. In restart_threads we call update_thread_list and spot the new thread. The thread is created with executing == true and state == THREAD_RUNNING, but, resumed == false. Back in restart_threads we then loop over all threads and try to put the thread "back to what they were trying to do back when we paused them for an in-line step-over." For our new thread we try to resume the thread (even though it's already running), which requires a read of $pc, which causes the error we see. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2021-05-07 14:16 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-07 14:16 andrew.burgess at embecosm dot com [this message] 2021-05-07 14:26 ` [Bug gdb/27830] " andrew.burgess at embecosm dot com 2021-05-10 17:27 ` andrew.burgess at embecosm dot com 2021-05-10 19:24 ` andrew.burgess at embecosm dot com 2022-06-21 11:28 ` pedro at palves dot net 2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org 2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org 2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org 2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org 2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org 2023-11-13 15:00 ` pedro at palves dot net
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-27830-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).