id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
366	No fork callback to safely use LIBC heap	dmik		"It turns out that even the callbacks registered with !__LIBC_PFORKHANDLE::pfnCompletionCallback that are called very last before returning from `fork()` to the user code are not safe for using LIBC itself: at least, an attempt to create a new log instance with `__libc_LogInit` aborts the forked child with
{{{
LIBC PANIC!!
fmutex deadlock: Owner died!
0x2003013c: Owner=0x25930001 Self=0x25940001 fs=0x3 flags=0x0 hev=0x00010004
            Desc=""LIBC Heap""
pid=0x2594 ppid=0x2592 tid=0x0001 slot=0x00ab pri=0x0200 mc=0x0000 ps=0x0010
D:\CODING\LIBCX\MASTER-BUILD-DEBUG\STAGE\BIN\TST-ANON_MMAP.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

_fmutex operation failed:  LIBC Heap request
}}}
It looks to me like it can't use its own heap by that time.

A fork callback when it's safe to use LIBC is very desirable. It would, in particular, allow to solve the infamous _DLL_InitTerm problem in forked children and similar 3rd party DLL initialization issues when the only way to initialize the DLL in the forked child is to do it in a delayed fashion, i.e. when a function requiring initialization is called for the first time. This is very annoying as it basically requires a check in all functions routing the execution to the initialization routine if it's not already called."	defect	new	normal	new	libc	0.6.6	normal			lewisr dryeo