Updates:
Summary: Crash On Renderer Main thread (probably just after task
completion/corruption)
Comment #8 on issue 8553 by [email protected]: Crash On Renderer Main thread
(probably just after task completion/corruption)
http://code.google.com/p/chromium/issues/detail?id=8553
Summary: It appears to be that in the render, the completion of some task
has caused
heap corruption (possibly the task itself). I'll have to go hunting for
other
(related) and common crashers to try to seek the true cause. I suspect the
involvement of the message loop is tangential to the problem.
Here are some more details.
I'm hard pressed to blame std::swap(), and I tried researching it via
google to find
similar crashes. The closest I came was that std::swap() induced some
malfunctions
recently when an attempt was made to use an iterator (into the swapped
dequeues
before and after the dequeue had been moved around via swap()). Unable to
claim that
swap has problems with memory alloc/free, I have to conclude the memory
(heap) was
corrupted "recently" so that this stack among the first places (after the
corruption)
that did memory alloc/free.
Looking up the stack, the critical point is that DoWork() is calling
ReloadWorkQueue(). This means that a tasks has *just* completed. There is
a chance
that DoWork only just finished queueing a timer task, but just completed is
the
likely thing that corrupts memory. Note that when a task is just
completed, the
message loop then does a free of the task (most of the time). The fact that
it
crashes in ReloadWorkQueue is no big deal, it is just that the internal
queue happens
to be empty, and the message_loop is swapping in the externally visible
queue to
start to service it. The mention of safe browsing (re: SBChunk) on the
stack is a
red herring, as several templated functions within swap() are merged to use
common
code (and slightly confuse the displayed stack trace, althought the stack
is probably
quite intact).
If the above conclusion is correct, the next things to look for is a
renderer crash
on the main thread, which means it contains:
[renderer_main.cc:120] - RendererMain(MainFunctionParams const &)
We can *hope* that the class of tasks that cause this crash are many, and a
similar
task is just starting (I don't know how else to guess what task just
finished...
<sigh>).
There is a chance that we'll see other main thread renderer crashes, and
they'll
actually happen as we try to delete the task... which would then hint that
the
corruption happened *before* the task deletion, and we might get a hint of
what the
task being run was.
bottom line: this stack trace needs to be merged with some other Renderer
crashes on
the main thread.
--
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
-~----------~----~----~----~------~----~------~--~---
