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).