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