Date: Sun, 5 Dec 2004 00:04:19 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 467 ************************************************** Saturday 04 December 2004 Number 467 ************************************************** Subjects for today 1 fork and !!!DEADLOCK!!! : lsunley at mb.sympatico.ca 2 Re: fork and !!!DEADLOCK!!! : Knut St. Osmundsen" **= Email 1 ==========================** Date: Fri, 03 Dec 2004 23:52:27 -0500 From: lsunley at mb.sympatico.ca Subject: fork and !!!DEADLOCK!!! Does anyone have a clue what this could mean DEBUG: Starting: StartChildProcess fork !!!deadlock!!! LIBC Heap Owner died! DEBUG: Starting: StartChildProcess fork pid = -1 LOG: could not fork startup process: Invalid argument This happens when postmaster.exe executes a pid = fork() Lorne -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 2 ==========================** Date: Sat, 04 Dec 2004 10:04:11 +0100 From: "Knut St. Osmundsen" Subject: Re: fork and !!!DEADLOCK!!! lsunley at mb.sympatico.ca wrote: > Does anyone have a clue what this could mean > > DEBUG: Starting: StartChildProcess fork > > !!!deadlock!!! LIBC Heap Owner died! > DEBUG: Starting: StartChildProcess fork pid = -1 > LOG: could not fork startup process: Invalid argument > > This happens when postmaster.exe executes a pid = fork() I fixed this problem a few days back. I thing I already reported that, but since you didn't pay attention you get the hear all the details about it now. ;-) It was caused by DLLs loaded by dlopen not begin loaded into the child on fork() as one should expect. The result was that a iconv or setlocale related function crashed when calling into one of the DLLs. This was caught by the exception handler and the process exitted. The very odd warning about the heap owner having died is because the process was a partial copy of the parent at the time and the heap hadn't been unlocked yet. Some cleanup code invoked by LIBC DLL termination code found that it wanted to call free(). Both issues have been fixed. I've added two new API wrappers, DosLoadModuleEx and DosFreeModuleEx, which will make sure that the loaded module will be loaded in the child processes too. And in the case of the termination code, it will is disabled while the fork is in progress and should not be invoked on failure. A third problem - which didn't occure because of the crash - was also corrected. The heap semaphores was owned by the parent, and releasing them in the child process would've caused the same message as above. Kind Regards, knut