[Bug nptl/30587] New: FAIL: nptl/tst-cleanupx4 on hppa

[Bug nptl/30587] New: FAIL: nptl/tst-cleanupx4 on hppa

[danglin at gcc dot gnu.org]

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

            Bug ID: 30587
           Summary: FAIL: nptl/tst-cleanupx4 on hppa
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: danglin at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

dave@atlas:~/gnu/glibc/objdir$ make test t=nptl/tst-cleanupx4
make -r PARALLELMFLAGS="" -C ../glibc objdir=`pwd` test
make[1]: Entering directory '/home/dave/gnu/glibc/glibc'
make subdir=nptl -C nptl/ ..=../
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.out
make[2]: Entering directory '/home/dave/gnu/glibc/glibc/nptl'
gcc tst-cleanupx4.c -c -std=gnu11 -fgnu89-inline  -g -O2 -Wall -Wwrite-strings
-Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector
-fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno    -fno-pie
-fexceptions        -I../include -I/home/dave/gnu/glibc/objdir/nptl 
-I/home/dave/gnu/glibc/objdir  -I../sysdeps/unix/sysv/linux/hppa 
-I../sysdeps/hppa/nptl  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread 
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/hppa/hppa1.1 
-I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32 
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/hppa/fpu  -I../sysdeps/hppa 
-I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc
-isystem /usr/lib/gcc/hppa-linux-gnu/12/include -isystem /usr/include
-D_LIBC_REENTRANT -include /home/dave/gnu/glibc/objdir/libc-modules.h
-DMODULE_NAME=testsuite -include ../include/libc-symbols.h      
-DTOP_NAMESPACE=glibc -o /home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.o -MD
-MP -MF /home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.o.dt -MT
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.o
gcc tst-cleanupx4aux.c -c -std=gnu11 -fgnu89-inline  -g -O2 -Wall
-Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition
-fmath-errno    -fno-pie -fexceptions        -I../include
-I/home/dave/gnu/glibc/objdir/nptl  -I/home/dave/gnu/glibc/objdir 
-I../sysdeps/unix/sysv/linux/hppa  -I../sysdeps/hppa/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix 
-I../sysdeps/posix  -I../sysdeps/hppa/hppa1.1  -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/hppa/fpu
 -I../sysdeps/hppa  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio
-I. -nostdinc -isystem /usr/lib/gcc/hppa-linux-gnu/12/include -isystem
/usr/include -D_LIBC_REENTRANT -include
/home/dave/gnu/glibc/objdir/libc-modules.h -DMODULE_NAME=testsuite -include
../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -o
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4aux.o -MD -MP -MF
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4aux.o.dt -MT
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4aux.o
gcc -o /home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4 -nostdlib -nostartfiles  
  -Wl,-z,relro  /home/dave/gnu/glibc/objdir/csu/crt1.o
/home/dave/gnu/glibc/objdir/csu/crti.o `gcc  --print-file-name=crtbegin.o`
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.o
/home/dave/gnu/glibc/objdir/support/libsupport_nonshared.a
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4aux.o 
-Wl,-dynamic-linker=/lib/ld.so.1
-Wl,-rpath-link=/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
-lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed
/home/dave/gnu/glibc/objdir/libc.so.6
/home/dave/gnu/glibc/objdir/libc_nonshared.a -Wl,--as-needed
/home/dave/gnu/glibc/objdir/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed
-lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o`
/home/dave/gnu/glibc/objdir/csu/crtn.o
env GCONV_PATH=/home/dave/gnu/glibc/objdir/iconvdata
LOCPATH=/home/dave/gnu/glibc/objdir/localedata LC_ALL=C  
/home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4  >
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.out; \
../scripts/evaluate-test.sh nptl/tst-cleanupx4 $? false false >
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4.test-result
make[2]: Leaving directory '/home/dave/gnu/glibc/glibc/nptl'
FAIL: nptl/tst-cleanupx4
original exit status 1
test 0
clh (2)
global = 2, expected 15
test 1
clh (4)
clh (6)
global = 30, expected 276
test 2
clh (8)
global = 8, expected 120
test 3
clh (2)
clh (10)
global = 30, expected 460

This failure was introduced by the following commit:

commit 20b6b8e8a50874dd189687df8f6f8a11d4813b34 (HEAD)
Author: Fr<C3><A9>d<C3><A9>ric B<C3><A9>rat <fberat@redhat.com>
Date:   Wed Jun 14 10:52:06 2023 +0200

    tests: replace read by xread

    With fortification enabled, read calls return result needs to be checked,
    has it gets the __wur macro enabled.

    Note on read call removal from  sysdeps/pthread/tst-cancel20.c and
    sysdeps/pthread/tst-cancel21.c:
    It is assumed that this second read call was there to overcome the race
    condition between pipe closure and thread cancellation that could happen
    in the original code. Since this race condition got fixed by
    d0e3ffb7a58854248f1d5e737610d50cd0a60f46 the second call seems
    superfluous. Hence, instead of checking for the return value of read, it
    looks reasonable to simply remove it.
    Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org,
                   |                            |siddhesh at sourceware dot org

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[fberat at redhat dot com]

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

Frédéric Bérat <fberat at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fberat at redhat dot com

--- Comment #1 from Frédéric Bérat <fberat at redhat dot com> ---
In principle, we could revert the change affecting nptl/tst-cleanup.c but I'm a
bit puzzled by this issue. It looks strange that it affects nptl/tst-cleanupx4
but not nptl/tst-cleanup4. The only difference between the 2 being the linkage.

Would there be a way to get access to some hppa hardware to do some more
investigation ?

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2023-06-27 10:08 a.m., fberat at redhat dot com wrote:
> Would there be a way to get access to some hppa hardware to do some more
> investigation ?
We have a machine, panama.parisc-linux.org, that is available for development
and testing.

Helge should be able to provide an account.

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2023-06-27 10:08 a.m., fberat at redhat dot com wrote:
> In principle, we could revert the change affecting nptl/tst-cleanup.c but I'm a
> bit puzzled by this issue. It looks strange that it affects nptl/tst-cleanupx4
> but not nptl/tst-cleanup4. The only difference between the 2 being the linkage.
Correct, only nptl/tst-cleanupx4 fails after change.

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[fberat at redhat dot com]

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

--- Comment #4 from Frédéric Bérat <fberat at redhat dot com> ---
Since I don't have the access yet, I'm looking at the logs:

test 0
clh (2)
global = 2, expected 15

This executes fn2(), which should basically do:
  pthread_cleanup_push (clh, (void *) 3l);
  _pthread_cleanup_push (&b, clh, (void *) 2l);
  pthread_cleanup_push (clh, (void *) 1l);

Whereas, from the output, only `_pthread_cleanup_pop (&b, 1);` seems to be
executed.

The same goes for the following iterations. It looks like only
_pthread_cleanup_pop actions get executed on cancellation.

I don't see how this could be induced by the aforementioned patch.

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
At least on qemu-user this test fail with or without the
20b6b8e8a50874dd189687df8f6f8a11d4813b34.

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |deller at gmx dot de

--- Comment #6 from Sam James <sam at gentoo dot org> ---
I can give access to another machine if Helge can't.

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[deller at gmx dot de]

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

--- Comment #7 from Helge Deller <deller at gmx dot de> ---
(In reply to Frédéric Bérat from comment #1)
> Would there be a way to get access to some hppa hardware to do some more
> investigation ?

Sure. Just send me your preferred login name and your public ssh key and I can
give you access to a machine. In case you have a debian developer key you can
directly log in to panama.parisc-linux.org.
Helge

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2023-06-27 12:02 p.m., fberat at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30587
>
> --- Comment #4 from Frédéric Bérat <fberat at redhat dot com> ---
> Since I don't have the access yet, I'm looking at the logs:
>
> test 0
> clh (2)
> global = 2, expected 15
>
> This executes fn2(), which should basically do:
>    pthread_cleanup_push (clh, (void *) 3l);
>    _pthread_cleanup_push (&b, clh, (void *) 2l);
>    pthread_cleanup_push (clh, (void *) 1l);
>
> Whereas, from the output, only `_pthread_cleanup_pop (&b, 1);` seems to be
> executed.
>
> The same goes for the following iterations. It looks like only
> _pthread_cleanup_pop actions get executed on cancellation.
>
> I don't see how this could be induced by the aforementioned patch.
It seems to me that the sequencing of the cleanups must be timing dependent. 
Simply changing
the read in tst-cleanup4.c to xread changes the test result from PASS to FAIL.

The test doesn't fail if xread is moved into tst-cleanup4.c.

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2023-06-27 4:26 p.m., dave.anglin at bell dot net wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30587
>
> --- Comment #8 from dave.anglin at bell dot net ---
> On 2023-06-27 12:02 p.m., fberat at redhat dot com wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30587
>>
>> --- Comment #4 from Frédéric Bérat <fberat at redhat dot com> ---
>> Since I don't have the access yet, I'm looking at the logs:
>>
>> test 0
>> clh (2)
>> global = 2, expected 15
>>
>> This executes fn2(), which should basically do:
>>     pthread_cleanup_push (clh, (void *) 3l);
>>     _pthread_cleanup_push (&b, clh, (void *) 2l);
>>     pthread_cleanup_push (clh, (void *) 1l);
>>
>> Whereas, from the output, only `_pthread_cleanup_pop (&b, 1);` seems to be
>> executed.
>>
>> The same goes for the following iterations. It looks like only
>> _pthread_cleanup_pop actions get executed on cancellation.
>>
>> I don't see how this could be induced by the aforementioned patch.
> It seems to me that the sequencing of the cleanups must be timing dependent.
> Simply changing
> the read in tst-cleanup4.c to xread changes the test result from PASS to FAIL.
>
> The test doesn't fail if xread is moved into tst-cleanup4.c.
The problem is xread.c is not compiled with "-fexceptions".  The
nptl/tst-cleanupx4 test
passes if xread.c is compiled with "-fexceptions".

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #10 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to dave.anglin from comment #9)
> The test doesn't fail if xread is moved into tst-cleanup4.c.
> The problem is xread.c is not compiled with "-fexceptions".  The
> nptl/tst-cleanupx4 test
> passes if xread.c is compiled with "-fexceptions".

Then this is not a regression but is a pre-existing problem with libsupport.a.

We need to compile the support routine infrastructure with "-fexceptions
-fasynchronous-unwind-tables" to make sure we can always unwind through the
wrappers which themselves may call functions which we know we can unwind
through.

This needs a patch to fix support/Makefile to add it to all routines.

Dave, Can you please propose a patch to do that?

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

[Bug nptl/30587] FAIL: nptl/tst-cleanupx4 on hppa

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #11 from John David Anglin <danglin at gcc dot gnu.org> ---
Fixed on master by commit 1d5024f4f052c12e404d42d3b5bfe9c3e9fd27c4.

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