Closed Bug 1208535 Opened 9 years ago Closed 9 years ago

crash in xul.dll@0x19fb6ee | Firefox crashes with certain NoScript settings with videos

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Version:
43 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1209132
Tracking Flags:
Tracking Status
firefox42 --- unaffected
firefox43 - ---
firefox44 - ---

People

(Reporter: marty6001, Unassigned)

Details

(Keywords: crash, crashreportid, regression)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150624141335 Steps to reproduce: Visit any site that loads videos (e.g. youtube or Dailymotion). Actual results: When NoScript is configured to block a video, i.e. in Options/Embeddings/Apply these restrictions to whitelisted sites too Firefox crashes when attempting to load it. Expected results: If a site uses flash or HTML5 and "Apply these restrictions to whitelisted sites too" is checked in NoScript the video displays a placeholder over the video requiring permission before playing the video. In Windows XP the placeholder is visible but clicking on it causes a crash. In Windows 7 Firefox crashes before the appearance of the placeholder. NoScript developers claim this is a Firefox bug and not the fault of the addon since the crash reason is EXCEPTION_ILLEGAL_INSTRUCTION. A crash report is here: https://crash-stats.mozilla.com/report/index/6cce16c2-fbaf-411d-beca-8058d2150924
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Severity: normal → critical
Crash Signature: [@ xul.dll@0x19fb6ee ]
Keywords: crash, crashreportid
Summary: Firefox crashes with certain NoScript settings with videos → crash in xul.dll@0x19fb6ee | Firefox crashes with certain NoScript settings with videos
How to block video with NS? I installed it in FF44 and it doesn't block YT video playback.
To the developers: I narrowed the crash start down to this build: 1442835936/ 21-Sep-2015 14:18
(In reply to Loic from comment #1) > How to block video with NS? I installed it in FF44 and it doesn't block YT > video playback. If you're using HTML5 video NS does not yet block it with a placeholder. You can force flash by disabling these settings in about:config: media.mediasource.mp4.enabled media.ogg.enabled media.webm.enabled As long as "Apply these restrictions to whitelisted sites too" is checked in Options/Embeddings then you will get a placeholder. This will work in current versions but if you try it in the latest nightly it will crash.
I disabled these prefs in about:config. I checked "Apply these restrictions to whitelisted sites too" in NS. I see the Flash placeholder but when I click on it, it doesn't crash, it displays a weird background with the same placeholder (maybe ad?) http://i.imgur.com/TMMA7l1.jpg
(In reply to Loic from comment #4) > I disabled these prefs in about:config. > I checked "Apply these restrictions to whitelisted sites too" in NS. > I see the Flash placeholder but when I click on it, it doesn't crash, it > displays a weird background with the same placeholder (maybe ad?) > http://i.imgur.com/TMMA7l1.jpg That's not an ad, just NoScript text. If you're not getting a crash a likely possibility is display issues. In Windows XP I at least still get the placeholder, but clicking on it crashes the browser. In Windows 7 it crashes even before the placeholder has a chance to appear. They are two different driver versions, though both the latest legacy AMD drivers.
Does disabling e10s ( https://support.mozilla.org/en-US/questions/1062853#answer-730519 ) change anything?
Flags: needinfo?(marty6001)
(In reply to Giorgio Maone from comment #6) > Does disabling e10s ( > https://support.mozilla.org/en-US/questions/1062853#answer-730519 ) change > anything? Tested with e10s on and off and it crashes no matter.
Flags: needinfo?(marty6001)
This is a Firefox bug. I disabled NoScript and installed the flashdisable addon but when tweaking flash on and off with a toolbar button it crashes in exactly the same way. Please fix, it has made watching videos impossible on any site that loads them, whether Flash or html5. The build when the bug first appeared is posted above.
I'm not able to reproduce the crash with your steps. :[ Is it specific to some hardware? OS?
It's occurring in XP and Windows 7. The crash report is in the first post but my guess is it's related to to the AMD video card/drivers. It wouldn't be the first time that crashes were specific to that hardware. Do you know how to determine what changes were made to each build? This one: 1442835936/21-Sep-2015 14:18 is when the crashes started so that's where I can look for the regression.
You will need to run the tool Mozregression for that. see http://mozilla.github.io/mozregression/ When it's installed, you create a custom profile with NS and all the settings you need to configure. After that, you run mozregression with this profile (reuse): mozregression --bits=32 --good=2015-09-20 --profile=/path/to/profile --profile-persistence=reuse Then copy here the changelog (from mozilla-inbound builds) provided in the console output.
This is the apparent regression: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6895a6883048a7166d9ce5e3917da27f3fb67c7&tochange=0783f2174228ea14bcfcaaed3fbff28b4fb56014 It looks to be it since it involves embedding/components/webbrowser. I do have the whole completed log if you need it.
Ty, no need, the changelog is enough.
status-firefox42: --- → unaffected
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?
Flags: needinfo?(mozilla)
Keywords: regression
Version: 44 Branch → 43 Branch
I don't think the patch from Bug 1206146 is responsible for the breakage, most likely it's Bug 1184798 which also caused other crashes similar to this one, see Bug 1208755. We can only be sure if someone could provide a stacktrace though. CC'ing myself and bkelly to keep an eye out for that breakage.
Flags: needinfo?(mozilla)
Did two do overs except I added the bad string --bad=2015-09-22 to Loic's line above. Both times the result came back as this and was from the Sept 20 inbound: 30:57.30 LOG: MainThread Bisector INFO Last good revision: 8eda15c59d265f755582342dd027e97959b2429b 30:57.30 LOG: MainThread Bisector INFO First bad revision: 5f6c252853022783cb6acbb91d00fd660c5d53e2 https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8eda15c59d265f755582342dd 027e97959b2429b&tochange=5f6c252853022783cb6acbb91d00fd660c5d53e2 So it is different from the original finding.
If you are not sure of the starting date range, you can try an older date like --good=2015-09-01.
The crash definitely first appears on the September 20th inbound. Mozregression downloaded a total of 4 builds on that day along with builds a few days before. The 18th and 19th were good.
Well it appears that I've gotten confirmation of Tooru Fujisawa's changes. Because the work involved IonMonkey I disabled javascript.options.ion and it no longer crashes. So that appears to be a temporary workaround for this bug.
(In reply to Marty from comment #19) > Well it appears that I've gotten confirmation of Tooru Fujisawa's changes. > Because the work involved IonMonkey I disabled javascript.options.ion and it > no longer crashes. So that appears to be a temporary workaround for this bug. Yes, that's correct. Your crash stems from the same underlying problem as bug 1209132.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
I should mention, thank you for testing on nightly and reporting the crash :) If you see any future EXCEPTION_ILLEGAL_INSTRUCTION crashes on that particular machine, please alert the developers that it's probably a missing SSE check. In my experience we accidentally mess this up on nightly several times a year. Having someone to point these out would help them get fixed faster!
I'm not sure if we need to track at this point but please re-nominate this for 43 and 44 if the volume is higher (or, if you come up with a fix, please request uplift) I'm only seeing one crash reported with this signature on crash-stats for the last month and that's for 44. The regression range doesn't fit with Christoph's suggested bug (which landed in nightly on 9-23). On the other hand, we have someone who can reproduce the bug and is willing to work on this. (Thanks Marty!) Let's see if bug 1208755 gets a fix. When that lands, maybe Marty could give it a try again to verify it fixes this crash too in 44.
Whoops. crossed comments with David. Thanks for the clarification!
tracking-firefox43: ? → -
tracking-firefox44: ? → -
Just ran the most recent inbound with javascript.options.ion re-enabled and there's no crash. For this machine at least the patch seems to have fixed the issue.
(In reply to David Major [:dmajor] from comment #21) > I should mention, thank you for testing on nightly and reporting the crash :) > > If you see any future EXCEPTION_ILLEGAL_INSTRUCTION crashes on that > particular machine, please alert the developers that it's probably a missing > SSE check. In my experience we accidentally mess this up on nightly several > times a year. Having someone to point these out would help them get fixed > faster! No problem, I download nightlies at least two or three times a week to test addons and to keep track of any updates/changes.
You need to log in before you can comment on or make changes to this bug.