NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/55241: Many t_ptrace_wait* test cases fail since Apr 16
The following reply was made to PR lib/55241; it has been noted by GNATS.
From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: lib/55241: Many t_ptrace_wait* test cases fail since Apr 16
Date: Thu, 7 May 2020 14:40:23 +0200
On Thu, May 07, 2020 at 11:15:01AM +0000, Andreas Gustafsson wrote:
> These test cases (and other t_ptrace_wait* test cases that were reported
> in separate mails) are still failing:
>
> http://releng.netbsd.org/b5reports/i386/2020/2020.05.06.09.18.10/test.html#failed-tcs-summary
>
> Most of them fail only under qemu, but the fork_signalmasked test
> cases are also failing on real hardware:
>
> http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2020/2020.05.06.20.40.33/test.html#failed-tcs-summary
AFAICT, the fork_singalmasked tests make invalid assumptions,
essentially:
get signal mask
fork()
set signal mask of child immediately on return to userland
This can't work in a world where the dynamic linker has to protect
against reentrance as it also has to deal with TLS access from signal
handlers. The tests can either defer the check e.g. by self-suspending
the child immediately after fork returns or drop this part, but the
observation they are trying to make is certainly only valid for the
actual fork system call, not the library frontend.
Joerg
Home |
Main Index |
Thread Index |
Old Index