Opened 10 years ago

Closed 3 years ago

#5723 closed bug (fixed)

fork() doesn't ensure a consistent state of libroot data

Reported by: bonefish Owned by: axeld
Priority: normal Milestone: R1
Component: System/ Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


When a thread of a multi-threaded team calls fork() other threads could execute critical sections in libroot protected by locks. The protected data might thus be in an inconsistent state in the child team. The locks might appear in a locked state (depending on their implementation) -- ATM they are reinitialized in atfork() hooks. A correct solution would be to register all problematic locks at a central point in libroot and in fork(), before calling the system, acquire them all.

Change History (2)

comment:1 by korli, 3 years ago

@bonefish, OK to close?

comment:2 by bonefish, 3 years ago

Resolution: fixed
Status: newclosed

The ticket is quite general, but since POSIX restricts, what can be done after fork() anyway, I guess the status quo -- the runtime loader and the memory allocator being safe -- should be OK.

Note: See TracTickets for help on using tickets.