NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: lib/53343: t_ptrace_wait*:traceme_vfork_crash_bus test cases fail



The following reply was made to PR lib/53343; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53343: t_ptrace_wait*:traceme_vfork_crash_bus test cases fail
Date: Wed, 6 Jun 2018 08:49:34 +0200

 On Tue, Jun 05, 2018 at 02:50:00PM +0000, Andreas Gustafsson wrote:
 > since the following commits:
 > 
 >   2018.05.30.17.31.34 kamil src/tests/kernel/h_segv.c 1.6
 >   2018.05.30.17.31.34 kamil src/tests/lib/libc/sys/t_ptrace_wait.h 1.10
 >   2018.05.30.17.48.13 kamil src/tests/kernel/h_segv.c 1.7
 >   2018.05.30.17.48.13 kamil src/tests/lib/libc/sys/t_ptrace_wait.h 1.11
 
 Looking at the diff I scratched my head and said "must be a kernel bug".
 
 There may, actually, be one hiding here. The child dumps core, but the
 core only is header and otherwise empty (so like 64byte). However, the
 parent does not get the proper status.
 
 But if you look at the name of the test (and the flow that happens in the
 source) it is quite clear that the test previously only worked due to
 plain luck. The vfork child process, while the parent is still blocked,
 does mmap() of a file to provoke the bus error. The mmap() call of course
 is strictly forbidden in this state (due to vfork restrictions).
 
 Kamil: I think we have to move the mmap() into the parent, and then trigger
 it in the child. Painfully complicating the test structure for this case,
 but should solve the issue.
 
 Martin
 


Home | Main Index | Thread Index | Old Index