Closed
Bug 1279851
Opened 5 years ago
Closed 5 years ago
CRASH when benchmarking webm decoding performance on YouTube page
Categories
(SeaMonkey :: General, defect)
Tracking
(seamonkey2.45 affected, seamonkey2.46 affected, seamonkey2.47 fixed, seamonkey2.48 fixed, seamonkey2.49esr fixed)
RESOLVED
WORKSFORME
seamonkey2.49
People
(Reporter: RainerBielefeldNG, Unassigned)
References
()
Details
(Keywords: 64bit)
Attachments
(2 files, 1 obsolete file)
Steps how to reproduce German SeaMonkey 2.44 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build 20160608085536 (Default Classic Theme) on German WIN7 64bit: 1. Launch SeaMonkey Browser 2. Click Link to Youtube "Kelsey and the Chaos - Wrapped Around Your Finger" <https://www.youtube.com/watch?v=Yktiod-uWuc> » After few moments SM will crash Additional information ---------------------- a) May be all Youtube is affected b) Also happens with existing test User Profile with minimum set of Add-Ons and only Flash player Plugin, all plugins and add-ons disabled c) But does not crash with minimum test User Profile in safe mode d) Crash reason from crash reports: "EXCEPTION_INT_DIVIDE_BY_ZERO" e) Crash reports: bp-b785c3e8-86c6-4714-a78f-6f22c2160613 <http://crash-stats.mozilla.com/report/index/bp-b785c3e8-86c6-4714-a78f-6f22c2160613> bp-55fa5d13-879e-449e-87b7-bbb4f2160613 <http://crash-stats.mozilla.com/report/index/bp-55fa5d13-879e-449e-87b7-bbb4f2160613> bp-f7d69a05-977b-44dd-80be-152a02160613 <http://crash-stats.mozilla.com/report/index/bp-f7d69a05-977b-44dd-80be-152a02160613> and others f) No crash with English SeaMonkey 2.45a1 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Build 20160308001946 (Default Classic Theme) on German WIN7 64bit g) Currently "critical", if the crash will be confirmed for 32bit a general YouTube crash would be a no-go. h) Be careful when test, you should use "Launch via Profile Manager" by default and use a separate test profile, or you should disable "Restore previous session". I ran into a crash loop 2 times because restored session crashed before I had time to open the "Restore Session?" question TAB (what might be a separate bug) I will do some more research later
Reporter | ||
Comment 1•5 years ago
|
||
i) I did not find an obvious DUP with <https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs1279851&sharer_id=41036>
Reporter | ||
Comment 2•5 years ago
|
||
k) Other video players (vimeo, facebook) are not affected
Reporter | ||
Comment 3•5 years ago
|
||
l) NOT reproducible REPRODUCIBLE with unofficial (from <http://seamonkey.callek.net/contrib/>) German SeaMonkey 2.44 Mozilla/5.0 (Windows NT 6.1; Win64; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build 20160608001333 (Default Classic Theme) on German WIN7 64bit m) Strange: A Profile having run Build 20160608001333 will no longer crash running with Build 20160608085536 afterwards. But a newly created Profile in Build 20160608085536 will immediately reproduce the Crash. Because 64bit builds will not be distributed as official builds no longer "critical". I currently don't know any further tests I can do.
Severity: critical → major
Summary: CRASH when open YouTube page → 64Bit: CRASH when open YouTube page
c. try disabling hardware acceleration > Edit | Preferences | Appearance | Content -> Use hardware acceleration when available e. msmpeg2adec.dll This http://www.howtogeek.com/forum/topic/mpeg-2-encoder-is-missing/page/2 points to http://www.nirsoft.net/utils/registered_dll_view.html, if you wanted to dabble, unregistering that dll & see if that makes any difference?
(Oops, didn't scroll down far enough to see this one too...) e. nvwgf2umx.dll One of many from a search..., https://steamcommunity.com/app/271590/discussions/0/535152276592090601/ (I don't really know the consequences of unregistering the dll's? Maybe something like that could be done in a VM?)
Reporter | ||
Comment 6•5 years ago
|
||
(In reply to therube from comment #4) > c. try disabling hardware acceleration That does not help, also crashes with h.a. disabled To do the dll tests would take some time for me because I haven't any competence in this area.
User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 SeaMonkey/2.44 Build identifier: 20160608085536 I confirm this for a minimal profile -- a profile with almost all settings at default. But SeaMonkey DOES NOT crash with my normal profile. Using the minimal profile: YouTube will reliably crash when media.webm.enabled is true, default. YouTube will reliably NOT crash when media.webm.enabled is false. But my normal profile doesn't crash either way. Except that I was able to make my normal profile crash on YouTube when I had made some settings changes but I didn't write them down and can't reproduce the crash now. I'll try to make my normal profile crash again after work, if nobody has an answer by then.
Oh, All my crash reports for this: bp-447d748b-4512-4d5b-b3b3-05e692160614 6/14/2016 1:51 PM bp-ecb79074-9807-4439-ade9-845a92160614 6/14/2016 1:48 PM bp-6390a54c-36cd-4c24-9792-5b7da2160614 6/14/2016 1:45 PM bp-bb4efa14-736a-4b27-a299-8b1a52160614 6/14/2016 1:35 PM bp-fb713139-8d64-42e5-b522-064662160614 6/14/2016 1:32 PM bp-9cfb3400-b2fe-49fd-9f26-99d8a2160614 6/14/2016 1:12 PM bp-72536e6d-898d-49a1-9c61-795302160614 6/14/2016 12:55 PM bp-3595b584-bab6-49ce-97f6-2f3282160614 6/14/2016 12:38 PM bp-4b808e10-666a-467e-9fa8-9e6b62160614 6/14/2016 12:35 PM bp-5bf61e7f-fc48-42fe-8a52-71b7c2160614 6/14/2016 12:33 PM
Reporter | ||
Comment 9•5 years ago
|
||
(In reply to benl from comment #7) > YouTube will reliably crash when media.webm.enabled is true, default. > YouTube will reliably NOT crash when media.webm.enabled is false. For me that seems not to be the single difference making SM crash. My normal profild "healed" by (m) has when media.webm.enabled = true > I'll try to make my normal profile crash again after work, Great, in the meanwhile I will try to find something in the .dll area NEW due to comment 7
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: 64Bit: CRASH when open YouTube page → 64Bit: newly created profile will CRASH when open YouTube page
Reporter | ||
Comment 10•5 years ago
|
||
n) I have some indication that something in prefs.js is responsible for the crash after following test: 11. Launch SM 2.44 64Bit → Create and use new profile → Provoke crash on Youtube » CRASH 12. Copy paste prefs.js to a safe folder ...\SEAMONKEY_BUGS\CRASH\crashes 13. Launch SM 2.44 32Bit with the same profile → goto to Youtube » NO CRASH 14. Copy paste prefs.js to a safe folder ...\SEAMONKEY_BUGS\CRASH\healed 15. Launch SM 2.44 64Bit with the same profile → goto to Youtube » NO CRASH, profile is healed 16. Quit SM 17. Copy/Paste prefs.js from ...\SEAMONKEY_BUGS\CRASH\crashes into test profile 18. Launch SM 2.44 64Bit with the same profile → goto to Youtube » CRASH has reappeared Attached test kit contains * both saved "pref.js" * Copies of both pref.js for comparison * prefs - Comparison.pdf what shows differences between both "pref.js" as colored text
Comment 11•5 years ago
|
||
User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 SeaMonkey/2.44 Build identifier: 20160608085536 Ok, I can get my normal profile to crash reliably when attempting to view YouTube videos if I: set media.webm.enabled to true (default) AND: EITHER: reset media.benchmark.vp9.fps to default (changes from an integer to a blank string) OR: reset media.benchmark.vp9.versioncheck to default (changes from an integer to a blank string) (presumably happens with both reset as well) Apparently vp9 is some webm video decoder. My theory is Mozilla wanted to benchmark users's vp9 performance but didn't consider what would happen if the benchmark preferences are missing. Since vp9 is in Firefox as well, maybe somebody should check 64-bit versions of Firefox to see if they crash with webm enabled and these benchmark preferences reset. I searched bugzilla for combinations of "vp9," "benchmark," and "webm" in the comments but nothing that looks like this bug.
Comment 12•5 years ago
|
||
> Attached test kit contains
> * both saved "pref.js"
> * Copies of both pref.js for comparison
> * prefs - Comparison.pdf what shows differences between both "pref.js" as
> colored text
Actually, none of that is in there.
Reporter | ||
Comment 13•5 years ago
|
||
Indeed, seems I rightlicked the neigbour for zipping :-( Testkit2.zip now with correct contents.
Attachment #8762788 -
Attachment is obsolete: true
Comment 14•5 years ago
|
||
32Bit also affected. http://crash-stats.mozilla.com/report/index/bp-273fcbff-4183-4566-ac7c-ac5e02160616 http://crash-stats.mozilla.com/report/index/bp-91b2fecb-a70f-4406-8aed-cba592160616 I couldn't seem to get FF 47 x64 to crash. Not clear on STR, a bit of this a bit of that. But those two crashes that I did get occurred straight away. Crashes do state, "EXCEPTION_INT_DIVIDE_BY_ZERO", & I'll guess that is just what is going on. A particular set of circumstances, most apt to occur when creating a new Profile, that results in this divide by zero, & well, there she goes. (In this day & age & div/0 still occurs :-(.) After those two crashes, I'm now having trouble forcing a crash again? Maybe also timing is involved or something like that? This sort of crash reminds me of the (one time) upgrade crash, Bug 1092810 - startup Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ].
Comment 15•5 years ago
|
||
Oh, & at least one of the crashes occurred with this page, https://www.youtube.com/html5 so actual "playback" of a video wasn't required, but more, I guess, the "inspection" (sniffing) of capabilities.
Reporter | ||
Comment 16•5 years ago
|
||
(In reply to therube from comment #15) > one of the crashes occurred with https://www.youtube.com/html5 REPRODUCIBLE with German SeaMonkey 2.44 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build 20160608085536 (Default Classic Theme) on German WIN7 64bit (In reply to therube from comment #14) > 32Bit also affected. l): For me NOT reproducible with unofficial (from <http://seamonkey.callek.net/contrib/>) German SeaMonkey 2.44 Mozilla/5.0 (en-US Language pack) (Windows NT 6.1; Win64; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build 20160608001333 (Default Classic Theme) on German WIN7 64bit Some additional conditions?
Summary: 64Bit: newly created profile will CRASH when open YouTube page → 64Bit(?): newly created profile will CRASH when open YouTube page
![]() |
||
Comment 17•5 years ago
|
||
Rainer, I am unable to reproduce this with my de and en-US 2.44 x64 builds in a vm. They are VS2015 Update 3 RC builds which might not have this bug. Would you like to try them out for comparision? I think it might be a driver problem.
![]() |
||
Comment 18•5 years ago
|
||
This is likely video driver related. On an older T61 with Nvidia card I can crash Seamonkey 2.44 x64 VS2015 build with https://www.youtube.com/html5. Same on a W500 with ATI using 2.44 and 2.45 x64 VS2015. Desktop with R9 280X and latest ATI driver is rock stable using 2.45 x64 VS2015. I am unable to crash it using the above url. I suspect Firefox 47 is also affected. Maybe someone can try it out. If not we need to check the compiler settings.
Comment 19•5 years ago
|
||
For me (crashing, comments 7,8,11) my video card is nvidia 670 and drivers 365.19 (latest as of about a month ago). about:support says: Driver Date: 5-9-2016 Driver Version: 10.18.13.6519 I dunno if it's a driver issue, what with me having the latest nvidia drivers for a common nvidia card. I found that media.benchmark.vp9.versioncheck will reappear after some period after it's been reset, so if you don't crash you have to see if either .versioncheck or .fps is still missing (assuming webm is enabled.) Also, if .versioncheck is reset while a YouTube video is open in a tab SeaMonkey must be restarted for it to cause a crash. Mr. Grahl, may I ask what your procedure is to get SeaMonkey to crash?
![]() |
||
Comment 20•5 years ago
|
||
I stand corrected. Not directly vidio driver related. Desktop also crashes when it tries to benchmark vp9 decoding. Just visiting https://www.youtube.com/html5 with javascript enabled does it. The crash is likely in or around dom\media\benchmark.cpp which was introduced in FF 47. As a non c++ programmer I can't make much of the code but seeing all the thread juggling and asynchronous tasks going on I am only surprised that this doesn't cause problems in FF 47 too... Workaround is to just set media.mediasource.webm.enabled to true. If you have problems on slower PCs you might need to disable webm processing for now. The crash doesn't always occur because the benckmark itself might complete and will not rerun itself if it finds the right preferences. On the W500 I had the .fps and the other needed prefs afterward so subsequent visits to the websites work. The desktop maybe is too fast. This is most visible on new profiles but has nothing to do with it. Likely a core bug but if FF is not affected we are on our own.
![]() |
||
Updated•5 years ago
|
Summary: 64Bit(?): newly created profile will CRASH when open YouTube page → CRASH when benchmarking webm decoding performance on YouTube page
![]() |
||
Comment 21•5 years ago
|
||
I tried with a debug build but no luck. The test works there so it's either a timing issue or an optimizer problem. I suspect the first. Building a debug build with motimize right now to verify. As another workaround you could also add the two bold prefs and put something meaningful in the fps one. The versioncheck needs to be 1 for now.
![]() |
||
Comment 22•5 years ago
|
||
An optimized debug build also didn't crash so this really does look like a timing issue. Maybe a use after free in one of the threads. My advise right now. Just set the webm setting via about:config to the desired values. FRG
Reporter | ||
Comment 23•5 years ago
|
||
Hartmut Figge did some tests with Linux (de.comm.software.mozilla.nightly-builds, "Bestaetigungsbitte: [Bug 1279851] 64Bit: CRASH when open YouTube page") was not able to provoke a crash.
![]() |
||
Comment 24•5 years ago
|
||
Good news everyone: The fix for Bug 1279348 seems to cure this. I asked for uplifting it but if we do a 2.45 we might need a separate branch. I am also quite sure it won't make it into Firefox 49. Tested with a local 2.46 with and without the fix and after backporting I can no longer reproduce it.
![]() |
||
Comment 25•5 years ago
|
||
Could someone test a recent Nightly or Aurora on Windows to see if this is gone after bug 1279348. Its fixed for me.
Reporter | ||
Comment 26•5 years ago
|
||
NOT reproducible with unofficial en-US SeaMonkey 2.49a1 (NT 6.1; X64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20160924005117 (Default Classic Theme) on German WIN7 64bit. WFM for now.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → seamonkey2.49
![]() |
||
Updated•5 years ago
|
status-seamonkey2.45:
--- → affected
status-seamonkey2.46:
--- → affected
status-seamonkey2.47:
--- → fixed
status-seamonkey2.48:
--- → fixed
status-seamonkey2.49esr:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•