On Apr 23, 2012, at 5:11 AM, Benjamin Thaut <[email protected]> wrote:
> Am 23.04.2012 13:57, schrieb Steven Schveighoffer: >> 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 > > 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.
