Closed Bug 1099274 Opened 10 years ago Closed 10 years ago

Crash reporter fails to submit report for e10s crashed tab (test case)

Categories

(Core :: DOM: Content Processes, defect)

All
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1068349
Tracking Status
e10s m4+ ---

People

(Reporter: jimm, Assigned: mconley)

References

Details

Attachments

(1 file)

STR:

On a win8 device with a touch screen:

1) turn on e10s
2) restart
3) force e10s on when prompted about a11y by visiting about:config, flipping browser.tabs.remote.autostart.disabled-because-using-a11y to false, and restarting.
4) open a simple web page

results:

1) tab crashes
2) Try Again button fails to do anything, or possibly repeatedly crashes (bad user experience)
3) about: crashes shows no crash signatures
There's no mention of this in the crash reporter's submit.log, and there's nothing in the profile's minidumps folder.
Component: General → DOM: Content Processes
Product: Firefox → Core
Blocks: 1050210
Assignee: nobody → wmccloskey
Assignee: wmccloskey → mconley
I am able to reproduce this, and the problem seems to be that we're not getting passed a dumpID when the ipc:content-shutdown notification is sent. Digging into why now...
I've determined that in this particular case, we're not creating a minidump. Trying to figure out why now...
Ok, here's what's going on:

I was able to reproduce this test case, not by opening up any old webpage, but by browsing to mozilla.org on a Surface Pro, and touching / dragging my finger across the touch interface on a few tiles.

At least in my test case, what's going on isn't a crash - it's infanticide.

The parent is killing the child in ContentParent::KillHard because of a MsgProcessingError on a ShowEvent message from DocAccessibleChild.

The child doesn't actually crash, so there's no crash report.
I would suspect that this similar instances of tabs "crashing" but not allowing crash uploads is because the parent is in fact killing the child.

I wonder if it'd be useful to submit a faux-crash report here, since this sort of thing can certainly happen to users. I think it'd be useful to know how often the parent is killing the child, and why.
So I think I've "solved" this one, but what are the actions here?

Do we want to find a way of submitting some kind of report when the parent kills the child? What do you think, jimm?
Flags: needinfo?(jmathies)
Is bug 1103279 possibly related?
Flags: needinfo?(jmathies)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #4)
> Ok, here's what's going on:
> 
> I was able to reproduce this test case, not by opening up any old webpage,
> but by browsing to mozilla.org on a Surface Pro, and touching / dragging my
> finger across the touch interface on a few tiles.
> 
> At least in my test case, what's going on isn't a crash - it's infanticide.
> 
> The parent is killing the child in ContentParent::KillHard because of a
> MsgProcessingError on a ShowEvent message from DocAccessibleChild.

There's some mention in the code here about getting a mini dump?

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#3047

is there something here that isn't working?
This might be bug 1096664 or bug 1096080, or maybe even bug 1099274.
(In reply to Jim Mathies [:jimm] from comment #9)
> This might be bug 1096664 or bug 1096080, or maybe even bug 1099274.

That last bug is probably a bit redundant.
Looking at the log[1] in bug 1103279, the message that's erroring out is PBrowser::Msg_Destroy. The handler returned false, so we kill the child.

So it's not the same reason, but I believe it's the same result - the parent flips out, and kills the child. No crash report, because the child didn't crash - the parent killed it.

[1]: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/amccreight@mozilla.com-7345732409cf/try-linux/try_ubuntu32_vm_test-mochitest-e10s-browser-chrome-1-bm01-tests1-linux32-build883.txt.gz
(In reply to Jim Mathies [:jimm] from comment #8)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #4)
> > Ok, here's what's going on:
> > 
> > I was able to reproduce this test case, not by opening up any old webpage,
> > but by browsing to mozilla.org on a Surface Pro, and touching / dragging my
> > finger across the touch interface on a few tiles.
> > 
> > At least in my test case, what's going on isn't a crash - it's infanticide.
> > 
> > The parent is killing the child in ContentParent::KillHard because of a
> > MsgProcessingError on a ShowEvent message from DocAccessibleChild.
> 
> There's some mention in the code here about getting a mini dump?
> 
> http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#3047
> 
> is there something here that isn't working?

I'm not entirely sure - I don't fully grok the multi-process underpinnings just yet. There might be some cases where we kill the child and a minidump exists, but I don't know what those would be... as far as I understand, killing the child prevents the child from creating a minidump in the first place.
Sounds like this is bug 1068349. Maybe Ted's comment will help.
Yes, this sounds exactly like bug 1068349.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: