Ticket #2087 (new defect)

Description

The problem is fork() and malloc() seems to be that malloc() (and other glibc functions) share a lock with fork(), so if a thread get suspended by the GC (through the SIGUSR1 signal) inside malloc() after taking the lock, when the GC tries to fork() it deadlocks, because fork() tries to acquire the lock grabbed by malloc(), which will not be released until the collection finishes and the threads are resumed, which will never happen because for this fork() should get the lock in the first place :)

A bug report that can be related to this is here: http://sourceware.org/bugzilla/show_bug.cgi?id=4737

Seems to be the same lock that makes fork() asyn-unsafe and that WONTFIX, so something should be done to prevent this in the GC.