[Bug gdb/29965] New: [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[Bug gdb/29965] New: [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

            Bug ID: 29965
           Summary: [gdb] FAIL:
                    gdb.threads/process-exit-status-is-leader-exit-status.
                    exp: iteration=1: continue (the program exited)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I'm running into:
...
[Inferior 1 (process 5636) exited with code 020]^M
(gdb) FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp:
iteration=1: continue (the program exited)
...

This is on openSUSE Tumbleweed release 20230102 at trunk commit b26c8438c71
("Un xfail the PR19719 test for the AArch64 architecture") with a revert of
commit cb25fdbb76e ("gdb: remove assertion in
psymbol_functions::expand_symtabs_matching") which I expect should not matter.

AFAIU, the test-case checks that the inferior exit status is that of the leader
thread, in other words 1, but instead it's 20, so it's the exit status of a
non-leader thread.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14558
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14558&action=edit
gdb.log

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, this suggests that gdb may be not wrong:
...
$ for n in $(seq 1 100); do
./outputs/gdb.threads/process-exit-status-is-leader-exit-status/process-exit-status-is-leader-exit-status
; echo $?; done
32
33
32
33
32
32
32
32
32
33
7
32
32
32
33
32
29
32
32
31
32
33
32
33
1
33
33
32
32
32
32
32
32
32
32
32
32
32
32
33
32
32
32
33
32
32
31
33
32
30
32
32
32
33
32
32
32
33
33
32
32
31
32
32
32
32
32
32
33
32
32
32
32
33
33
32
32
32
32
32
32
32
33
32
33
32
32
32
32
33
32
32
32
32
32
32
33
32
33
32
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
In contrast on openSUSE Leap 15.4 I see:
...
$ for n in $(seq 1 100); do
./outputs/gdb.threads/process-exit-status-is-leader-exit-status/process-exit-status-is-leader-exit-status
; echo $?; done
1
  ...
1
$ 
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, kernel version 6.1.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
This linux kernel commit (first include in release v6.1.0) looks interesting:
...
commit d80f7d7b2c75c5954d335dffbccca62a5002c3e0
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Jun 21 14:38:52 2022 -0500

    signal: Guarantee that SIGNAL_GROUP_EXIT is set on process exit

    Track how many threads have not started exiting and when the last
    thread starts exiting set SIGNAL_GROUP_EXIT.

    This guarantees that SIGNAL_GROUP_EXIT will get set when a process
    exits.  In practice this achieves nothing as glibc's implementation of
    _exit calls sys_group_exit then sys_exit.  While glibc's implemenation
    of pthread_exit calls exit (which cleansup and calls _exit) if it is
    the last thread and sys_exit if it is the last thread.

    This means the only way the kernel might observe a process that does
    not set call exit_group is if the language runtime does not use glibc.

    With more cleanups I hope to move the decrement of quick_threads
    earlier.

    Link:
https://lkml.kernel.org/r/87bkukd4tc.fsf_-_@email.froward.int.ebiederm.org
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lsix at lancelotsix dot com,
                   |                            |palves at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> with a revert of
> commit cb25fdbb76e ("gdb: remove assertion in
> psymbol_functions::expand_symtabs_matching") which I expect should not
> matter.

Confirmed, FAILs also reproduce without the revert, so with clean trunk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
First step, filed at https://bugzilla.suse.com/show_bug.cgi?id=1206926

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[iii at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

Ilya Leoshkevich <iii at linux dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iii at linux dot ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #8 from Simon Marchi <simon.marchi at polymtl dot ca> ---
Proposed patch to add xfail here:
https://inbox.sourceware.org/gdb-patches/20230908015356.406003-1-simon.marchi@efficios.com/T/#u

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/29965] [gdb] FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=1: continue (the program exited)

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29965

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ea186080fe2b94b21f3ac8ad7941948211d5e67a

commit ea186080fe2b94b21f3ac8ad7941948211d5e67a
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Thu Sep 7 21:53:55 2023 -0400

    gdb/testsuite: add xfail for gdb/29965 in
gdb.threads/process-exit-status-is-leader-exit-status.exp

    Bug 29965 shows on a Linux kernel >= 6.1, that test fails consistently
    with:

        FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp:
iteration=0: continue (the program exited)
        ...
        FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp:
iteration=9: continue (the program exited)

    This is due to a change in Linux kernel behavior [1] that affects
    exactly what this test tests.  That is, if multiple threads (including
    the leader) call SYS_exit, the exit status of the process should be the
    exit status of the leader.  After that change in the kernel, it is no
    longer the case.

    Add an xfail in the test, based on the Linux kernel version.  The goal
    is that if a regression is introduced in GDB regarding this feature, it
    should be caught if running on an older kernel where the behavior was
    consistent.

    [1] https://bugzilla.suse.com/show_bug.cgi?id=1206926

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29965
    Change-Id: If6ab7171c92bfc1a3b961c7179e26611773969eb
    Approved-By: Tom de Vries <tdevries@suse.de>

-- 
You are receiving this mail because:
You are on the CC list for the bug.