Closed Bug 1333698 Opened 4 years ago Closed 3 years ago
Firefox crashes after standby when mynoise
.net is open
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161208153507 Steps to reproduce: 1. Visit mynoise.net and play a soundscape, for example: https://mynoise.net/NoiseMachines/ricefieldSoundscapeGenerator.php 2. Place pc in standby (suspend to RAM) 3. Unsuspend Actual results: Firefox has crashed and shows the crash manager. Expected results: Firefox should still have been alive. If mynoise.net is not open, the problem does not occur. Whether the tab is muted or not does not seem to matter; if the tab is present the issue occurs. Following crash IDs have previously been submitted and are the same issue: bp-b19e0c8e-7d5c-4bf3-b2fb-53a612170111 bp-cfd771f8-dc55-43e1-8c0b-ac6092170109
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID 20170129194105 Hi Thomas, I haven't managed to reproduce the issue you are experiencing on the latest Firefox release (51.0.1) or on the latest Nightly (54.0a1). I've loaded the page in question in a new tab and then I placed the PC in "Suspend", after a few minutes I "woke up" the PC and everything was fine. Also the crash reports that you've posted seem to be missing some symbols :( , you could get a better stack if you download an official Mozilla binary. https://www.mozilla.org/en-US/firefox/new/ for release. https://nightly.mozilla.org for the latest nightly. Please try to reproduce the issue on both the latest release and nightly and provide your results. When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/AR5o9d).
Thanks @cmuresan for your feedback. Give me some time to try and reproduce using your tips, and I will report back.
Hey Thomas, Have you had any time to retest the issue like I requested in comment 1?
Hi Ciprian, Thanks for the reminder and sorry for the delay. I have now taken the time to investigate further based on your suggestions. On nightly (firefox-54.0a1.en-US.linux-x86_64.tar.bz2) I could not reproduce, but I also could not hear any sound. I'm not sure why audio does not work in this Firefox version, but I'm convinced that that is the reason why there is no reproduction. On stable (firefox-51.0.1.tar.bz2) I could reproduce with a fresh profile and safe mode. I used this URL: https://mynoise.net/NoiseMachines/campingRainNoiseGenerator.php but otherwise the same test procedure as originally reported. You do not need to wait minutes during standby, I power on after seconds and can reproduce. I have submitted a new crash report for this crash: https://crash-stats.mozilla.com/report/index/290053df-4d50-46b7-b5d4-2ee492170215 As I mentioned in the comments there, the console shows the following upon wake up: $ ./firefox/firefox --ProfileManager --safe-mode plugin-container: /builds/slave/m-rel-l64-00000000000000000000/build/src/media/libcubeb/src/cubeb_alsa.c:320: alsa_refill_stream: Assertion `wrote >= 0 && wrote == got' failed. ###!!! [Parent][MessageChannel] Error: (msgtype=0x2E007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2E007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv I hope this information helps you in investigating further. If there is anything else I can do, just let me know.
Based on this info, I found bug #1130155 which contains a patch for seemingly the same cubeb_alsa assert but in a different context: bug 1021761 comment 45. However, that bug #1130155 is marked as fixed in 50 and 51 but the code in the patch is NOT what I see from the crash report I made: https://hg.mozilla.org/releases/mozilla-release/annotate/327e081221b0/media/libcubeb/src/cubeb_alsa.c#l320 I'm not familiar enough with Firefox development to understand what happened here...
Component: Untriaged → Audio/Video: cubeb
Product: Firefox → Core
This is a P1 bug without an assignee. P1 are bugs which are being worked on for the current release cycle/iteration/sprint. If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
This issue is fixed by bug 1247056.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1247056
You need to log in before you can comment on or make changes to this bug.