On Mon, 23 Apr 2012 02:41:21 -0400, Benjamin Thaut
<[email protected]> wrote:
I wrote a small "bad example" program for a presentation. It calls
malloc/free very frequently and I wanted to profile the impact of this
compared to a pool allocator solution. Unfortunately I had to notice
that the program only runs for a fraction of a second before
deadlocking. As it seems the following situation accurs:
1) Thread 1 calls malloc(), and locks the internal malloc mutex
2) Thread 2 triggers garbage collection and stops thread 1
3) Thread 2 is done collecting garbage and calls all destructors. One of
these calls free(), as the malloc mutex is still locked by Thread 1 and
Thread 1 will never release the mutex, as it is stoped, Thread 2
deadlocks.
This shouldn't happen. The collection routine is specifically designed to
avoid this. I remember when Sean put it into Tango after an IRC
conversation.
The correct sequence is:
1. stop the world
2. Perform mark on all data (identifying which blocks should be freed)
3. resume the world
4. Call dtors on unreferenced data and deallocate.
This was to fix the exact problem you are having, albeit the malloc/free
were indirect by calls to C-libs.
Please file a bug.
-Steve
