907804 - DelayedDeleteContentParentTask destroying ContentParent while still having calls on the stack

Status: RESOLVED INCOMPLETE

(Core :: IPC, defect)

Description

[Georg Fritzsche [:gfritzsche]]

Not sure what component to track this bug in...

Bug 864112 that tracks "mismatched CxxStackFrame ctor/dtors" aborts (and predates ContentParent usage) turned up this report (bug 864112, comment 20):

> I just got this crash and been able to make the following steps which
> crashes with this signature sometimes but it can be seen large amounts of
> memory even without it crashing so it will hopefully help.
> 
> These steps make use of the OOP thumbnail process and about:memory on
> Windows 8 desktop.
> 
> 1. In a new profile (even in your normal one, I get better crash percentage
> with my normal one) open about:memory.
> 2. Measure memory. It should be quite quick.
> 3. Open a new blank tab which has the dashboard thing.
> 4. Make certain that a thumbnail is being generated. Can be done by dragging
> a bookmark into dashboard box.
> 5. Quickly go back to about:memory and measure.
> 6. Repeat measure every time it finishes. No point continuing if the
> thumbnail process ends though.
> 
> You will notice that huge amounts of memory are getting used in the main
> browser (I have seen 700MB+ in spike) while its collecting the reports and
> the browser will be hung, sometimes with script timeout a couple of times
> per collection.
> 
> Here is a crash report I made as I was typing this in a brand new profile
> using steps above.
> https://crash-stats.mozilla.com/report/index/43be4c82-b3ca-4c9f-ac98-
> b6aa52130820

Sadly we don't see stack frames above ShowSlowScriptDialog, but if we hit that abort it means that a channel is spinning the event loop further up the stack and we're actually in an IPC call.
The plugin code deals with similar scenarios by delaying destruction until it's not nested anymore:
http://hg.mozilla.org/mozilla-central/annotate/1d6bf2bd4003/dom/plugins/ipc/PluginModuleParent.h#l112
http://hg.mozilla.org/mozilla-central/annotate/1d6bf2bd4003/dom/plugins/ipc/PluginModuleParent.cpp#l286

... it looks like either:
* ContentParent needs the same protection here or
* something further up the stack invalidly triggered this

Comment 1

[Georg Fritzsche [:gfritzsche]]

bent, do you have an opinion on whether delaying the destruction is the right call here or if there has something gone wrong further up the stack already?

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Ugh, this looks nasty. Am I right that it is only possible for there to be a slow script dialog on top of an IPC call if we're dealing with plugin RPC messages?

If so then we probably can't do anything but delay the destruction. 

However, if there's any other way for this to happen (CPOW?) then we should work very hard to prevent spinning the event loop here.

Comment 3

[Georg Fritzsche [:gfritzsche]]

Hm, good question; i was just assuming there were no plugins involved.
Hugh, can you still trigger this with all plugins being disabled or "Ask to activate" in Tools->Addons->Plugins?

Comment 4

[Hugh Nougher [:Hughman]]

Attachment: Parent Process.PNG

https://crash-stats.mozilla.com/report/index/addfdf16-ef55-4555-a2ae-a9ffb2130826
All plugins on never activate in new profile.

Also might be useful is the attached screenshot of main process CPU/Memory usage see from Process Explorer. I actually ran through my steps twice (first thumbnail process closed at first peak). I also noted that the memory reporter in main process of queued IPC messages was always 0.

Comment 5

[Hugh Nougher [:Hughman]]

Its amazing how easily I can hit this. To look at memory usage I start a new tab, navigate to about:memory and then click measure. The new tab _always_ starts a thumbnail process because I use sync and some of the selections are in another network so can never get a thumbnail.

Comment 6

[Hugh Nougher [:Hughman]]

I believe this is harder to hit with this testcase now that Bug 917489 has landed.

Comment 7

[Timea Cernea [:tbabos][inactive]]

Hi Hugh,
Is this issue still reproducible on the latest Firefox version? The last update on this was 8 years ago and it should be closed if it is no longer reproducible.

Comment 8

[Hugh Nougher [:Hughman]]

Dashboard that generates thumbnails doesn't even exist any more.
I have no idea what else would generate thumbnails so I cannot really answer if there is still an issue.
But no, I cannot reproduce to a non-existent dashboard.

Comment 9

[Timea Cernea [:tbabos][inactive]]

Thanks for answering! Unfortunately, there is no resolution like "Outdated" but will mark this as incomplete since as you also mentioned, that functionality doesn't exist anymore.