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

Status: RESOLVED DUPLICATE of bug 1068349

(Core :: DOM: Content Processes, defect)

Description

[Jim Mathies [:jimm]]

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

Comment 1

[Jim Mathies [:jimm]]

There's no mention of this in the crash reporter's submit.log, and there's nothing in the profile's minidumps folder.

Comment 2

[Mike Conley (: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...

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I've determined that in this particular case, we're not creating a minidump. Trying to figure out why now...

Comment 4

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 7

[Jim Mathies [:jimm]]

Is bug 1103279 possibly related?

Comment 8

[Jim Mathies [:jimm]]

(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?

Comment 9

[Jim Mathies [:jimm]]

This might be bug 1096664 or bug 1096080, or maybe even bug 1099274.

Comment 10

[Jim Mathies [:jimm]]

(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.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

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/[e-mail]-7345732409cf/try-linux/try_ubuntu32_vm_test-mochitest-e10s-browser-chrome-1-bm01-tests1-linux32-build883.txt.gz

Comment 12

[Mike Conley (:mconley) (:⚙️)]

(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.

Comment 13

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Sounds like this is bug 1068349. Maybe Ted's comment will help.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Yes, this sounds exactly like bug 1068349.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bugnotes

http://people.mozilla.org/~mconley2/bugnotes/bug-1099274.html