1390886 - Push messages causing front tabs to crash

Status: RESOLVED DUPLICATE of bug 1362764

(Core :: DOM: Push Subscriptions, defect)

Description

[Reinhard Herzfeld]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170810180547

Steps to reproduce:

1. Open a website that produces push messages (e.g. Hipchat, web.whatsapp.com, web.telegram.org)
2. Focus another tab or window, so the website is inactive and actually sends push messages
3. Receive a push message


Actual results:

Firefox shows the pushed message as a toast, however after a few seconds it shows a dialog shows up, stating firefox has crashed.

55 and 56 Branch, 32 bit and 64 bit tested with empty (new) profile.

Comment 1

[Kohei Yoshino]

Please send a crash report and paste ID here. https://support.mozilla.org/kb/mozillacrashreporter

Comment 2

[Reinhard Herzfeld]

There usually is no crash reporter, only a dialog stating that firefox is working no longer with two options - close or debug.

about:crashes only shows one crash report for yesterday whilst there where many tab crashes, so it may not be related to this issue:
https://crash-stats.mozilla.com/report/index/90ab65c8-6774-4033-81c0-a7d040170816

Comment 3

[Reinhard Herzfeld]

In case the crash report is relevent the issue might be related to bug 1362764 which is fixed on 57 branch.
I tested on nightly and cannot produce crashes there.

Comment 4

[Andrew Overholt [:overholt]]

Matthew, should we uplift the fix (new version of cubeb) from bug 1362764 to 55 and/or 56?
Ted, do you know who knows about the crash reporter and why this person wouldn't be getting one (see comment 2)?

Comment 5

[(not currently active) Ted Mielczarek]

(In reply to Reinhard Herzfeld from comment #2)
> There usually is no crash reporter, only a dialog stating that firefox is
> working no longer with two options - close or debug.

You're referring to the Windows dialog like this?
https://img.raymond.cc/blog/wp-content/uploads/2009/08/program_has_stopped_working_error.png

In general, unless someone has done something to disable it we should always get the crash reporter when the browser crashes. Given that there are crash reports referenced in bug 1362764 I don't think this is a crash that breaks the crash reporter in some way (at least not all the time), so maybe it's something in this particular environment? It doesn't seem like it's completely broken on this user's machine either, given the crash report link in comment 2.

It's possible this crash occasionally trips some Windows security protection that causes the OS to terminate Firefox in a way that we can't capture.

Reinhard: can you look in the Windows Event Viewer and see if you can find log events for the times when Firefox crashed and didn't give you the Mozilla crash reporter?
https://www.digitalmastersmag.com/magazine/tip-of-the-day-how-to-find-crash-logs-on-windows-10/

Comment 6

[Matthew Gregan [:kinetik]]

(In reply to Andrew Overholt [:overholt] from comment #4)
> Matthew, should we uplift the fix (new version of cubeb) from bug 1362764 to
> 55 and/or 56?

Yes.  There's a beta-approval request in bug 1386957 that has been waiting for approval since last week.  It'd be a fairly safe fix to uplift to 55 if we're doing a point release.

Comment 7

[Matthew Gregan [:kinetik]]

Reinhard, would you mind sharing some details about your sound hardware that triggered the crash report mentioned in comment 2?  The easiest way to get that info is to run dxdiag.exe from Start->Run and click "Save All Information", then attach the resulting .txt file to the bug.  I only need the audio secion, so feel free to delete anything else in the file if you prefer.

Comment 8

[Andrew Overholt [:overholt]]

(In reply to Matthew Gregan [:kinetik] from comment #6)
> (In reply to Andrew Overholt [:overholt] from comment #4)
> > Matthew, should we uplift the fix (new version of cubeb) from bug 1362764 to
> > 55 and/or 56?
> 
> Yes.  There's a beta-approval request in bug 1386957 that has been waiting
> for approval since last week.  It'd be a fairly safe fix to uplift to 55 if
> we're doing a point release.

Thanks. Ryan, do you know if we've got another dot release planned?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

302 Sylvestre.

Comment 10

[Reinhard Herzfeld]

Attachment: dxdiag sound info

Comment 11

[Sylvestre Ledru [:Sylvestre]]

We might do one for bug 1389160. We are not 100 % that it is a driver for a dot release yet.

Seems that it is pretty small volume, not sure that I would take this one as ride along.

Comment 12

[Reinhard Herzfeld]

Attachment: Windows application event log of (some) firefox crashes, starting with version 55

Comment 13

[(not currently active) Ted Mielczarek]

(In reply to Reinhard Herzfeld from comment #12)
> Created attachment 8898933 [details]
> Windows application event log of (some) firefox crashes, starting with
> version 55

Thanks! All the crashes in that log show "Exception code: 0xc0000374", which is apparently heap corruption:
https://blogs.msdn.microsoft.com/calvin_hsia/2015/01/30/heap-corruption-exception-0xc0000374/

That seems bad. It might be interesting to see if we could find any of these crashes in Microsoft's Windows Error Reporting setup?

Comment 14

[(Away)]

Jim, do you get any "Exception code: 0xc0000374" reports from WER?

Comment 15

[Reinhard Herzfeld]

Matthew, the file with audio information is attached.
After some more testing I can say that apparently it is the Jabra Pro 9450 causing the crashes as they only happen when this is the selected device.
Also, switching between the Jabra and any other device while an audio (or video) stream is active won't work seamlessly. The stream has to be stopped and restarted which sometimes causes crashes, too.

Everything works as expected in nightly, though.

Comment 16

[Matthew Gregan [:kinetik]]

Thanks for the information Reinhard!  That fits with the behaviour I saw in bug 1362764 with the MT202pcs device.  Some devices (probably devices supporting a very limited set of audio formats, e.g. mono and one sample rate, perhaps) trigger a different code path in the OS's audio APIs that we weren't handling correctly, resulting in the crashes and heap corruption observed in this bug and the others.

Comment 17

[Jim Mathies [:jimm]]

(In reply to David Major [:dmajor] from comment #14)
> Jim, do you get any "Exception code: 0xc0000374" reports from WER?

None of the crash descriptions references this exception.

Comment 18

[Andrew Overholt [:overholt]]

I'm going to dupe this to bug 1362764 since it's not really Push-related but more audio-related. Please correct me if I'm wrong! :)