About zombies - this is a part of the lifetime of every process.When a process exits, it becomes a zombie. It will stay a zombie until the parent process does a wait() for it, to read out the exit status. If the parent exits without every reading out the status, the process gets reparented to the init process, who then reads out the exit status.
Once the exit status have been read out, the zombie process goes away.So you need to figure out why the parent isn't doing the wait(). It might be that this should be triggered by a signal, and the signal is blocked. It might be that this should happen after some time, or in some specific thread, in which case you need to check why it isn't getting there. Maybe some mutex or other shared resource between threads have not been properly handled before the fork. One have to remember that any other threads do not survive in the child process after a fork, and that can sometimes cause issues because the author didn't think about possible implications.
Anyway - maybe this gives some helpful ideas... Johnny On 2025-01-24 10:21, Peter Skvarka wrote:
Thank you Taylor ! Unfortunately I am not able to create minimal sample.It happens in wxWidgets library function wxExecute() used by Codeblocks IDE and I can reproduce it only with started codeblocks process. The code of wxExecute() is complicated and it is problem to extract only essential parts and create minimal reproducer. I have this additional info: Forked parent retrieves child output through pipe and it waits for child finishing with select() infinitely and child stays zombie - I am seeing flag Z in ps -auxd list. I checked command line arguments passed to execv(), it is ok ("gcc - dumpversion") Child's C++ code from fork() to execv() does not uses pthread synchronization objects, it only prepares pipes and calls execv(). So it is question if reason is bad using of fork() in multithreaded application, or for example bad usage of pipes or something other. I think that it is NetBSD specific thing because of no similar report on other os-es.Currently I have debug built and I am trying to retrieve more info why forked child stays zombie. Do you think that is possible to diagnose or to debug with gdb phase of changing state to zombie ?Or to look on some child's process structuresWhat is real reason for zombie state ? Can it be holding of not closed pipe or file ? Or it can stay zombie when it is terminated from another process ? Is possible to investigate what resource is not freed by process which can be reason for entering into zombie state ?On 1/23/25 09:08, Taylor R Campbell wrote:Date: Wed, 22 Jan 2025 16:47:13 +0100 From: Peter Skvarka<ps%softinengines.com@localhost> On my NetBSD 10.1 I am trying to run multithreaded application where first are created several threads and then is called fork() from main thread. Forked child then calls execvp() . Passed command line (in argv argument) is "gcc", "-dumpversion". Application freezes because it waits for finishing child and ps -auxd shows child process "(gcc)" with flag zombie. I have two questions: Is safe using of fork() in NetBSD 10.1 in mutlithreaded application ?Generally yes, with the caveat that it is difficult for applications to use correctly. For example, if you have any application-specific locks, you usually have to take them carefully in a pthread_atfork handler to avoid deadlock in the child. Do you have a minimal reproducer for the unexpected behaviour you're seeing? I just tried with the attached program and it worked fine. $ ./hack 10.5.0 thread ran $Does NetBSD 10.1 support "set follow-fork-mode child" when used /usr/bin/gdb ? I can step through source code of forked child only on-two lines not more.Not sure offhand if it works, but if it doesn't work it's probably a bug that should be reported separately (https://gnats.NetBSD.org).
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol