Comment #7 on issue 8553 by [email protected]: Crash - RtlpLowFragHeapFree http://code.google.com/p/chromium/issues/detail?id=8553
This is just a summary of what I could see so far. There is no final conclusion... just notes. The crash is taking place in the message_loop when we (under protection of a lock) are trying to swap() out the externally visible queue of tasks for an empty thread- local queue of tasks. The external queue is always protected by the lock, and it is what allows other threads to post tasks to our loop asynchronously (under protection of the lock). The internal (thread local) queue is what we generally pop tasks from to run them. The question is: How can a swap operation induce a crash in free()? Looking at the traces, it appears that the deletion of a portion of a dequeue is the problem, which suggests that the portion has already been deleted (or else there is heap corruption <gulp>). My first guess was that either the source or the destination of the swap() was being asynchronously acted upon. I verified that all accesses to the external queue were indeed protected by our lock, and I also verified that all access to the thread-local queue were made inside the message loop. I need to verify that there are no other external entry points that could allow another thread access our internal queue. In all cases of access of the internal (thread local) queue, we appear to be cautious to only test for empty() and then grab the front() and do a pop(). None of those operations retains an iterator or any other internal access that could be corrupted (by a re-entrant call-out that modified any of these data structures). I'll investigate further tomorrow, and I'll probably try to look for operations that were *just* completed on the stack before performing the swap, on the expectation that we *just* corrupted the heap. I've (historically) seen bugs where we dropped a ref to a message loop, causing it to be destroyed, and in turn causing memory errors. In this case the message loop appears to be the main renderer thread and loop. I need to examine the lifetime of that loop. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs -~----------~----~----~----~------~----~------~--~---
