From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 199FF3857B92; Thu, 8 Sep 2022 15:29:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 199FF3857B92 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1662650990; bh=06oA9Kd8GB7yXWYuigsBjViLe1/TSZqrjG7JdZXJi28=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kPmX/YuMwv8vlR5b5L7PUSdr4TseVPwC3jXvo4EYTDLpJitbXjY12UjxZ9s5yWJCb lYfFdIgVqAbHOxz8D3YG6U0dW4PdJdIHKkUmCthFTWSuuz2x59e2KIs2n+ABrmaIDM H95CR5kkcGeEcWjCnQ6xfxGGqaTpZEIKKkTwQFbA= From: "simon.marchi at polymtl dot ca" To: gdb-prs@sourceware.org Subject: [Bug rust/29550] Segmentation fault in infrun.c Date: Thu, 08 Sep 2022 15:29:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: rust X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simon.marchi at polymtl dot ca X-Bugzilla-Status: UNCONFIRMED 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=3D29550 --- Comment #3 from Simon Marchi --- Thanks, I was able to reproduce with those instructions. We arrive in this state because an exception is thrown here: (gdb) bt #0 0x00007f6f7baa5f91 in __cxxabiv1::__cxa_throw (obj=3D0x60e0000063a0, tinfo=3D0x561aa4ff23e8 , dest=3D0x561aa41= 6284c ) at /usr/src/debug/gcc/libstdc++-v3/libsupc++/eh_throw.cc:81 #1 0x0000561aa4ecc871 in throw_it(return_reason, errors, const char *, typ= edef __va_list_tag __va_list_tag *) (reason=3DRETURN_ERROR, error=3DGENERIC_ERRO= R,=20 fmt=3D0x561aa0735640 "\"%s\": could not open as an executable file: %s.= ", ap=3D0x7ffff0b73440) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:200 #2 0x0000561aa4ecc913 in throw_verror (error=3DGENERIC_ERROR, fmt=3D0x561a= a0735640 "\"%s\": could not open as an executable file: %s.", ap=3D0x7ffff0b73440) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:208 #3 0x0000561aa49deeda in verror (string=3D0x561aa0735640 "\"%s\": could no= t open as an executable file: %s.", args=3D0x7ffff0b73440) at /home/smarchi/src/binutils-gdb/gdb/utils.c:164 #4 0x0000561aa4ee117c in error (fmt=3D0x561aa0735640 "\"%s\": could not op= en as an executable file: %s.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:46 #5 0x0000561aa30a213c in exec_file_attach (filename=3D0x6060000367a0 "target:/home/smarchi/src/northstar/target/release/northstar", from_tty=3D0= ) at /home/smarchi/src/binutils-gdb/gdb/exec.c:457 #6 0x0000561aa3bc99f8 in clone_program_space (dest=3D0x613000008540, src=3D0x613000004640) at /home/smarchi/src/binutils-gdb/gdb/progspace.c:210 #7 0x0000561aa345bf83 in follow_fork_inferior (follow_child=3Dtrue, detach_fork=3Dtrue) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:578 #8 0x0000561aa345eb42 in follow_fork () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:794 #9 0x0000561aa3493342 in handle_inferior_event (ecs=3D0x7ffff0b744c0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:5728 #10 0x0000561aa3480cae in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4233 #11 0x0000561aa33c96d4 in inferior_event_handler (event_type=3DINF_REG_EVEN= T) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41 #12 0x0000561aa36a2c1e in handle_target_event (error=3D0, client_data=3D0x0= ) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4216 #13 0x0000561aa4ee32fe in handle_file_event (file_ptr=3D0x60700001a650, ready_mask=3D1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:= 574 #14 0x0000561aa4ee3c3a in gdb_wait_for_event (block=3D0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:695 #15 0x0000561aa4ee16e8 in gdb_do_one_event (mstimeout=3D-1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217 #16 0x0000561aa461e45d in wait_sync_command_done () at /home/smarchi/src/binutils-gdb/gdb/top.c:546 #17 0x0000561aa461e675 in maybe_wait_sync_command_done (was_sync=3D0) at /home/smarchi/src/binutils-gdb/gdb/top.c:563 #18 0x0000561aa461fb69 in execute_command (p=3D0x7ffff0b77633 "", from_tty= =3D1) at /home/smarchi/src/binutils-gdb/gdb/top.c:694 #19 0x0000561aa37a3799 in catch_command_errors (command=3D0x561aa461e692 , arg=3D0x7ffff0b77632 "c", from_tty=3D1, do_bp_actions=3Dtrue) at /home/smarchi/src/binutils-gdb/gdb/main.c:513 #20 0x0000561aa37a4035 in execute_cmdargs (cmdarg_vec=3D0x7ffff0b752d0, file_type=3DCMDARG_FILE, cmd_type=3DCMDARG_COMMAND, ret=3D0x7ffff0b74f90) at /home/smarchi/src/binutils-gdb/gdb/main.c:608 #21 0x0000561aa37a8300 in captured_main_1 (context=3D0x7ffff0b75770) at /home/smarchi/src/binutils-gdb/gdb/main.c:1299 #22 0x0000561aa37a8981 in captured_main (data=3D0x7ffff0b75770) at /home/smarchi/src/binutils-gdb/gdb/main.c:1320 #23 0x0000561aa37a8a63 in gdb_main (args=3D0x7ffff0b75770) at /home/smarchi/src/binutils-gdb/gdb/main.c:1345 #24 0x0000561aa1dd88ce in main (argc=3D16, argv=3D0x7ffff0b75908) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32 The exception is thrown by exec_file_attach before we call target_follow_fo= rk.=20 The latter is responsible for pushing the process target on the child inferior's target stack. So inf->pid was assigned, but the process target = slot stays nullptr. While unwinding (while the exception is propagating), maybe_set_commit_resumed_all_targets gets called and we hit the segfault. After investigating for a bit, I think this is what happens: - Process A, is initially in the same mnt namespace as GDB. Its program_space::exec_filename contains /home/smarchi/src/northstar/target/release/northstar, which is a path in th= at mnt namespace. - Process A changes to a different mnt namespace. - Process A forks, which creates process B, which is automatically in that other mnt namespace. - While handling the fork and setting up the inferior for process B, GDB clones process A's program_space, calling exec_file_attach with /home/smarchi/src/northstar/target/release/northstar, the path still in pro= cess A's program_space::exec_filename. - GDB sees that process B is in a different mnt namespace, so it tries to access /home/smarchi/src/northstar/target/release/northstar in that other m= nt namespace. This fails, because /home/smarchi/src/northstar/target/release/northstar is a path in the origi= nal namespace. I was able to reproduce using a program that unlinks itself before forking: $ cat fork.c #include #include int main(int argc, const char **argv) { unlink (argv[0]); fork (); return 0; }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 $ gcc fork.c -g=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 $ ./gdb -nx -q --data-directory=3Ddata-directory a.out -ex "set follow-fork= -mode child" -ex r Reading symbols from a.out... Starting program: /home/smarchi/build/binutils-gdb/gdb/a.out=20 [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". [Attaching after Thread 0x7ffff7dbd740 (LWP 227302) fork to child process 227305] [New inferior 2 (process 227305)] /home/smarchi/src/binutils-gdb/gdb/infrun.c:2899:24: runtime error: member access within null pointer of type 'struct process_stratum_target'=20=20=20 This causes the same crash, because exec_file_attach can't find the file. However, it's not exactly the same situation. In the situation with the mnt namespaces, the file still (typically) exists on the original namespace, so= GDB could (and should, I think) open it and read it. GDB would need to remember which mnt namespace that path came from. So, these two cases should be fix= ed and tested separately. --=20 You are receiving this mail because: You are on the CC list for the bug.=