NetBSD-Bugs archive

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

misc/59380: t_ptrace_kill is flaky



>Number:         59380
>Category:       misc
>Synopsis:       t_ptrace_kill is flaky
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 01 01:55:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBPTrace Signalaction
>Environment:
>Description:
1. Sometimes it fails with:

.../t_ptrace_kill.c:131: waitpid(pid, &status, 0) != pid: waitpid(pid, &status, 0) got No child processes

2. Sometimes it fails with:

.../t_ptrace_kill.c:115: ptrace(7, pid, (void *)1, 0) != 0: ptrace(PT_CONTINUE, pid, (void *)1, 0) got Device busy

It is not obvious to me, either from reading the racy test program or from reading the cited PR toolchain/58896: gdb sometimes hangs on exit instead of killing inferior processes, what conditions this test program is supposed to exercise.

The thread the parent creates is waiting in waitpid(child, ..., 0) when the main thread does waitpid(child, ..., WNOHANG) and ignores the result -- what is the point?  Surely at least one of them should verify that waitpid returned WIFSTOPPED or something?  Why is there reading and writing back and forth between the parent and the child, instead of having the child just do for (;;) sleep(1)?

Other issues:

3. The SYSCALL macro reports errno, but it is also used for pthread_create, which does not set errno.
>How-To-Repeat:
cd /usr/tests/lib/libc/sys
atf-run t_ptrace_kill | atf-report
>Fix:
Yes, please!

1. I dunno, work out a clearer idea of who is supposed to waitpid for what when?

2. Either resolve some race here, or, if it is unavoidable: while (ptrace(...) == -1) { ATF_REQUIRE_ERRNO(EBUSY, 1); } // ptrace can fail with EBUSY if it doesn't get a p_reflock reader

3. Use RZ from h_macros.h.  Also use RL from h_macros.h for the -1 failure syscalls -- let's avoid a proliferation of different error checking macros.



Home | Main Index | Thread Index | Old Index