From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C29493858C56; Tue, 26 Apr 2022 12:42:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C29493858C56 From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug gdb/29091] New: Regression in gdb.base/foll-fork.exp and other fork-related tests Date: Tue, 26 Apr 2022 12:42:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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, 26 Apr 2022 12:42:39 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29091 Bug ID: 29091 Summary: Regression in gdb.base/foll-fork.exp and other fork-related tests Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: simark at simark dot ca Target Milestone: --- Commit 152a1749566 ("gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related test failures, such as: info inferiors^M Num Description Connection Executable ^M * 1 process 634972 1 (native)=20=20=20=20=20=20=20=20=20=20 /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/f= oll-fork/foll-fork ^M 2 process 634975 1 (native)=20=20=20=20=20=20=20=20=20=20 /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/f= oll-fork/foll-fork ^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=3Dparent: detach-on-fork=3Doff: cmd=3Dnext 2: test_follow_fork: info inferiors inferior 2^M [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/= foll-fork/foll-fork)]^M [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=3Dparent: detach-on-fork=3Doff: cmd=3Dnext 2: test_follow_fork: inferior 2 continue^M Continuing.^M [Inferior 2 (process 634975) exited normally]^M [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=3Dparent: detach-on-fork=3Doff: cmd=3Dnext 2: test_follow_fork: continue until exit at continue unfollowed inferior to end break callee^M Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=3Dparent: detach-on-fork=3Doff: cmd=3Dnext 2: test_follow_fork: break callee What happens here is: - inferior 2 is selected - we continue, leading to inferior 2's exit - we set breakpoint, expect 2 locations, but only one location is resolved Reading between the lines, we understand that inferior 2 got pruned, when it shouldn't have been. The issue can be reproduced by hand with: $ ./gdb -q --data-directory=3Ddata-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off"= -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun" ... Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14 14 int v =3D 5; [New inferior 2 (process 637627)] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 17 if (pid =3D=3D 0) /* set breakpoint here */ [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/= foll-fork/foll-fork)] [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))] #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6 (gdb) continue Continuing. [infrun] clear_proceed_status_thread: 637627.637627.0 [infrun] proceed: enter [infrun] proceed: addr=3D0xffffffffffffffff, signal=3DGDB_SIGNAL_DEFA= ULT [infrun] scoped_disable_commit_resumed: reason=3Dproceeding [infrun] start_step_over: enter [infrun] start_step_over: stealing global queue of threads to step, length =3D 0 [infrun] operator(): step-over queue now empty [infrun] start_step_over: exit [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: resuming 637627.637627.0 [infrun] resume_1: step=3D0, signal=3DGDB_SIGNAL_0, trap_expected= =3D0, current thread [637627.637627.0] at 0x7ffff7d7abf7 [infrun] do_target_resume: resume_ptid=3D637627.637627.0, step=3D0, sig=3DGDB_SIGNAL_0 [infrun] infrun_async: enable=3D1 [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop [infrun] reset: reason=3Dproceeding [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native [infrun] proceed: exit [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=3Dhandling event [infrun] do_target_wait: Found 2 inferiors, starting at #1 [infrun] random_pending_event_thread: None found. [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =3D [infrun] print_target_wait_results: 637627.637627.0 [process 637627= ], [infrun] print_target_wait_results: status->kind =3D EXITED, exit_s= tatus =3D 0 [infrun] handle_inferior_event: status->kind =3D EXITED, exit_status = =3D 0 [Inferior 2 (process 637627) exited normally] [infrun] stop_waiting: stop_waiting [infrun] stop_all_threads: start: reason=3Dpresenting stop to user in all-stop, inf=3D-1 [infrun] stop_all_threads: pass=3D0, iterations=3D0 [infrun] stop_all_threads: 637624.637624.0 not executing [infrun] stop_all_threads: pass=3D1, iterations=3D1 [infrun] stop_all_threads: 637624.637624.0 not executing [infrun] stop_all_threads: done [infrun] stop_all_threads: end: reason=3Dpresenting stop to user in all-stop, inf=3D-1 [Switching to Thread 0x7ffff7c9a740 (LWP 637624)] [infrun] infrun_async: enable=3D0 [infrun] reset: reason=3Dhandling event [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads (gdb) [infrun] fetch_inferior_event: exit (gdb) info inferiors Num Description Connection Executable * 1 process 637624 1 (native)=20=20=20=20=20=20=20=20=20=20 /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/f= oll-fork/foll-fork (gdb) i th Id Target Id Frame * 1 Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17 After handling the EXITED event for inferior 2, inferior 2 should have stayed the current inferior, which should have prevented it from getting pruned. When debugging, we find that when getting at the prune_inferiors call, the current inferior is inferior 1. Further debugging shows that prior to the call to clean_up_just_stopped_threads_fsms, the current inferior is inferior 2, and after, it's inferior 1. Then, back in fetch_inferior_event, the restore_thread object is disabled, due to: /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the previously selected thread is gone. We have two choices - switch to no thread selected, or restore the previously selected thread (now exited). We chose the later, just because that's what GDB used to do. After this, "info threads" says "The current thread has terminated." instead of "No thread selected.". */ if (!non_stop && cmd_done && ecs->ws.kind () !=3D TARGET_WAITKIND_NO_RESUMED) restore_thread.dont_restore (); So in the end, inferior 1 stays current, and inferior 2 gets wrongfully pruned. Proposed patch here: https://sourceware.org/pipermail/gdb-patches/2022-April/188309.html --=20 You are receiving this mail because: You are on the CC list for the bug.=