From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 59A4B38983BD; Tue, 28 Nov 2023 09:31:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 59A4B38983BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1701163901; bh=7I7gHIQpls1WP+AITYE+oNxlCNWskCk3+R8n8J04hPw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bdBBTVKhX1txO1NRFY01nQFcMUrqYkKMC61lt4r5eEks87DiI2PgugayKiL9/7ZjV Gt4Vhe4VMZrb4mtCmKnhFL9PuoTEf39108oKUW4L6+1uZKy2ALaDSiWAWt66ds9ncB Z3iEmgcQRVhH6eBY0WG2DygiCzi7aLEmdrgPZAb8= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/30547] [gdb, s390x, ppc64] segfault in for_each_block Date: Tue, 28 Nov 2023 09:31:41 +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: 13.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: --- 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30547 --- Comment #9 from Sourceware Commits --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D14414227bfac= 8ef1803715b3b642f8ba0ab6fff8 commit 14414227bfac8ef1803715b3b642f8ba0ab6fff8 Author: Tom de Vries Date: Tue Nov 28 10:31:25 2023 +0100 [gdb] Fix segfault in for_each_block, part 2 The previous commit describes PR gdb/30547, a segfault when running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x). The root cause for the segmentation fault is that linux_is_uclinux give= s an incorrect result: it returns true instead of false. So, why does linux_is_uclinux: ... int linux_is_uclinux (void) { CORE_ADDR dummy; return (target_auxv_search (AT_NULL, &dummy) > 0 && target_auxv_search (AT_PAGESZ, &dummy) =3D=3D 0); ... return true? This is because ppc_linux_target_wordsize returns 4 instead of 8, causi= ng ppc_linux_nat_target::auxv_parse to misinterpret the auxv vector. So, why does ppc_linux_target_wordsize: ... int ppc_linux_target_wordsize (int tid) { int wordsize =3D 4; /* Check for 64-bit inferior process. This is the case when the host= is 64-bit, and in addition the top bit of the MSR register is set. */ long msr; errno =3D 0; msr =3D (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0); if (errno =3D=3D 0 && ppc64_64bit_inferior_p (msr)) wordsize =3D 8; return wordsize; } ... return 4? Specifically, we get this result because because tid =3D=3D 0, so we get errno =3D=3D ESRCH. The tid =3D=3D 0 is caused by the switch_to_no_thread in handle_vfork_child_exec_or_exit: ... /* Switch to no-thread while running clone_program_space, so that clone_program_space doesn't want to read the selected frame of a dead process. */ scoped_restore_current_thread restore_thread; switch_to_no_thread (); inf->pspace =3D new program_space (maybe_new_address_space ()= ); ... but moving the maybe_new_address_space call to before that gives us the same result. The tid is no longer 0, but we still get ESRCH because the thread has exited. Fix this in handle_vfork_child_exec_or_exit by doing the maybe_new_address_space call in the context of the vfork parent. Tested on top of trunk on x86_64-linux and ppc64le-linux. Tested on top of gdb-14-branch on ppc64-linux. Co-Authored-By: Simon Marchi PR gdb/30547 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30547 --=20 You are receiving this mail because: You are on the CC list for the bug.=