From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3EC22385703B; Tue, 1 Dec 2020 02:57:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EC22385703B From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug gdb/24694] FAIL: gdb.multi/multi-arch-exec.exp: first_arch=1: selected_thread=1: follow_exec_mode=same: continue across exec that changes architecture (Couldn't get registers: No such process) Date: Tue, 01 Dec 2020 02:57:25 +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: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simark at simark dot ca 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: cc 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: Tue, 01 Dec 2020 02:57:25 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24694 Simon Marchi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simark at simark dot ca --- Comment #8 from Simon Marchi --- This is due to an exec race. We have two threads - leader thread, doing the exec - other thread, minding its own business Things to remember are: - GDB resumes threads one by one, one after the other - When a multi-threaded program execs, regardless of which thread did the e= xec, all non-leader threads disappear and it looks like the leader is now execut= ing the new executable. When we do a "continue" after stopping at the all_started function, GDB tri= es to resume leader first, then other. In the failing case, leader has the ti= me to run its exec before GDB tries to resume the other thread. So the ptrace resume on the other thread fails with Couldn't get registers: No such process. That aborts the resumption command and causes unexpected output, making the test fail. Since this particular test is not about testing this particular corner case= , I think we can avoid it by adding a synchronization point after the continue,= so the exec only happens after both threads were resumed. But I also think we should handle the situation better. When resuming mult= iple threads and one of them fails with "no such process", we should probably pr= int a warning but carry on, not abort the continue. There would be a separate = test for that (or whatever behavior we decide to have). --=20 You are receiving this mail because: You are on the CC list for the bug.=