Closed Bug 1245713 Opened 8 years ago Closed 8 years ago

Not creating crash dumps for the content process when we should on Linux

Categories

(Core :: DOM: Content Processes, defect, P1)

Product:
Core
Component:
DOM: Content Processes
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 481781
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: mconley, Assigned: billm)

References

Details

(Whiteboard: e10st?) 

STR:

1) With e10s enabled, view the attachment in bug 1245474 on Linux
2) Crash

ER:

There should be a crash report submission form.

AR:

There is no crash report submission form.

Note that on Windows, I get a crash report, so something strange is going on in the Linux case.
Note that the "sendAsyncMessge" error message will appear in this case, which will be tempting as a potential culprit for this bug, but that error is being caused by the lack of the dump and is being fixed in bug 1242907.

That will not fix the lack of a crash dump though, and that's what this bug is all about.
See Also: → 1242907
I was hitting this earlier today with a different crash, too. Very occasionally, I would actually get a crash-report submission form, but most of the time I did not. (I ended up filing that bug as bug 1245679.)

All of which is to say: be aware, when testing, that you might occasionally get Expected Results here, and there may be some sort of race condition or similar subtlety here.
At least for the crash caused by bug 1245474, it looks like the TabCrashHandler is not receiving a dump ID in the ipc:content-shutdown observer.
Ted, sounds like a break pad issue, can you look into it?
Flags: needinfo?(ted)
Assignee: nobody → wmccloskey
tracking-e10s: ? → +
Priority: -- → P1
I probably don't have time to actively investigate this right now. I did a quick test on my Linux nightly on Ubuntu, and installing my crashme extension and using its "Crash content process" option gets me the normal tab crash UI, so I don't think it's fundamentally broken.

In the other bug mconley suggested this was a stack overflow, in which case this is probably just the (long-standing) bug 481781?
Flags: needinfo?(ted)
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #5)
> installing my crashme
> extension and using its "Crash content process" option gets me the normal
> tab crash UI

Same here. (Same with "kill -11 [content-process-id]".)  So I think Ted's right, at least about the crash that happens with bug 1245474's testcase.

Per comment 2, I was also hitting this bug yesterday with a TreeHerder crash that didn't seem to be a stack overflow (though I'm not sure)... We may not be able to follow up on that much, though, without reliable STR, I guess. :-/
Whiteboard: e10st?
Breakpad's ExceptionHandler::SignalHandler() does not get called in the child process for the crash of bug 1245474's test case. However it is called with "kill -11".
Looks like a dupe of bug 481781, reopen if you think it's not.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.