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