GC + malloc/free = deadlock

[Sean Kelly]

On Apr 23, 2012, at 5:11 AM, Benjamin Thaut <code at benjamin-thaut.de> wrote:

> Am 23.04.2012 13:57, schrieb Steven Schveighoffer:
>> On Mon, 23 Apr 2012 02:41:21 -0400, Benjamin Thaut
>> <code at benjamin-thaut.de> 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
> 
> If what you are saying is true, the deadlock must happen somewhere else. This was kind of a assumption because the deadlock happend after I added all the malloc / free calls. Because all the threads are stopped when this happens I can't really debug this, because the Visual Studio debugger tells me that it can not debug any thread but the one that is currently running the GC.
> 
> Kind Regards
> Ingrater

You should be able to get stack traces for all threads, even the suspended ones.