1279851 - CRASH when benchmarking webm decoding performance on YouTube page

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect, major)

Description

[Rainer Bielefeld]

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

Comment 1

[Rainer Bielefeld]

i) I did not find an obvious DUP with <https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs1279851&sharer_id=41036>

Comment 2

[Rainer Bielefeld]

k) Other video players (vimeo, facebook) are not affected

Comment 3

[Rainer Bielefeld]

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.

Comment 4

[therube]

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?

Comment 5

[therube]

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

Comment 6

[Rainer Bielefeld]

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

Comment 7

[benl]

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.

Comment 8

[benl]

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

Comment 9

[Rainer Bielefeld]

(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

Comment 10

[Rainer Bielefeld]

Attachment: Test kit

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

[benl]

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

[therube]

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

Comment 13

[Rainer Bielefeld]

Attachment: Test kit 2

Indeed, seems I rightlicked the neigbour for zipping :-(

Testkit2.zip now with correct contents.

Comment 14

[therube]

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

[therube]

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.

Comment 16

[Rainer Bielefeld]

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

Comment 17

[Frank-Rainer Grahl (:frg)]

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

[Frank-Rainer Grahl (:frg)]

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

[benl]

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

[Frank-Rainer Grahl (:frg)]

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.

Comment 21

[Frank-Rainer Grahl (:frg)]

Attachment: Capture.PNG

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

[Frank-Rainer Grahl (:frg)]

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

Comment 23

[Rainer Bielefeld]

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

[Frank-Rainer Grahl (:frg)]

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

[Frank-Rainer Grahl (:frg)]

Could someone test a recent Nightly or Aurora on Windows to see if this is gone after bug 1279348. Its fixed for me.

Comment 26

[Rainer Bielefeld]

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.