Closed Bug 520929 Opened 15 years ago Closed 15 years ago

[HTML5] Minefield crashes instantly when visiting http://twitter.com/ [@nsHtml5TreeOpExecutor::ExecuteScript() ]

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: geeknik, Assigned: hsivonen)

References

(
URL
)

Details

(Keywords: crash, regression, topcrash, Whiteboard: [#1 trunk (3.7a1) topcrash])

Crash Data

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091006 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091006 Minefield/3.7a1pre

Open up the 6 October 2009 build of Minefield, type in twitter.com and watch Minefield crash.

http://crash-stats.mozilla.com/report/index/dff9455b-7eba-4abb-8725-5b0172091006?p=1
http://crash-stats.mozilla.com/report/index/0fced32b-c553-4466-9ccf-b9bf02091006?p=1
http://crash-stats.mozilla.com/report/index/1e8d95c0-7649-4a8d-b087-711ab2091006?p=1

I'm also seeing random crashes of the same type on other sitse including Youtube.com.

Reproducible: Always

Actual Results:  
Crash.

Expected Results:  
No crash.

Windows 7 Pro, 64-bit, Retail release version via MS TechNet. Core2Quad Q6600 (2.4ghz), 8GB DDR2-800, etc.
Keywords: crash
Version: unspecified → Trunk
Summary: [HTML5] Minefield crashes instantly when visiting http://twitter.com/ → [HTML5] Minefield crashes instantly when visiting http://twitter.com/ [@nsHtml5TreeOpExecutor::ExecuteScript() ]
Just a note.. If I toggle html5.enable to false, the crash goes away. Once I set it back to true, the crash comes back.
Assignee: nobody → hsivonen
blocking2.0: --- → ?
this crashe is not only with twitter, i am randomly encountered this with bugzilla and crash-stats.mozilla.com when i middle click links.

bp-4a7c6f18-8ce3-4a28-91ee-f3f442091006
bp-967baf98-03d8-4430-918f-747db2091006
bp-79bca9f6-1b92-4d95-a09a-ebb762091006
bp-e0b02774-46e7-4733-a22b-f09732091006

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091006 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091006044117
blocking2.0: ? → ---
Got about 10 of these myself with current nightly, I had to take html5 off to to forums...
Noticed from crash stats that all of these are from Win7 ?

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091006 Minefield/3.7a1pre Firefox/3.5.3 ID:20091006044117
I'd say this is wanted for 1.9.2, but not a blocker given that this code is preffed off by default.

Would be really nice to get it fixed though (hence the 'wanted' status), so that this doesn't get in the way of people testing the HTML5 parser for web compatibility.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.2+
Flags: blocking1.9.2?
blocking2.0: --- → ?
Keywords: topcrash
Agreed, not blocking on this, but Henri, if you come up with a fix in time for the release candidate we'll surely consider including it!
Status: NEW → UNCONFIRMED
blocking2.0: ? → ---
Ever confirmed: false
Flags: blocking1.9.2? → blocking1.9.2-
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
The crash location cited in the bug summary doesn't exist on the 1.9.2 branch.

I'm not seeing this crash on Mac. Is anyone else seeing this on Mac? In any case, it is likely that subsequent patches in the off-the-main-thread patch queue end up fixing this once they land.
Seems to be fixed in the latest nightly.
Nevermind, still crashing on my desktop, but not on my laptop for some reason. Only appreciable difference is that the desktop is running Windows 7 where the laptop is running Windows Vista. Also getting a crash on Youtube with HTML5 on, though that may be a different bug. (if I right click the Home button and open in a new tab, it crashes almost all the time with HTML5 on)
#7: Probably won't see this on your Mac since it's been pointed out this is an  HTML5 crash that is happening only on Windows 7 (at this point).
Any ideas why Windows 7 might be different? Is there anything on the twitter home page that causes a nested event loop to be created on the main thread? I didn't immediately see sync XHR.
It looks like this topcrash started in the 2009-10-06 nightly (just like bug 521668).
Whiteboard: [#1 trunk (3.7a1) topcrash]
Huh, how can this be the #1 topcrash? Or a topcrash at all? This code isn't even enabled by default.

I guess a lot of people on nightlies has HTML5 parsing enabled, but that it would make topcrash really surprises me.
(In reply to comment #13)
> Huh, how can this be the #1 topcrash? Or a topcrash at all? This code isn't
> even enabled by default.
> 
> I guess a lot of people on nightlies has HTML5 parsing enabled, but that it
> would make topcrash really surprises me.

Most of us (probably close to all) enabled this to play with once the code was checked in and haven't had any real problems since a couple days after the code landed.  Now that they are crashing all over the place, this became a top crasher and I'm guessing more than a few have kept the preference set to true despite the crashiness.
(In reply to comment #12)
> It looks like this topcrash started in the 2009-10-06 nightly (just like bug
> 521668).

The only relevant landing I can think of is bug 518104, but that went in on 2009-10-07. Could it have made it to the 2009-10-07 nightly?

I'll make a tryserver build with a substantial chunk of my mq so that Windows 7 users can test if the problem goes away with non-trivial changes that I've already applied locally to the relevant code.
(In reply to comment #15)
> (In reply to comment #12)
> > It looks like this topcrash started in the 2009-10-06 nightly (just like bug
> > 521668).
> 
> The only relevant landing I can think of is bug 518104, but that went in on
> 2009-10-07. Could it have made it to the 2009-10-07 nightly?

Yes. In Pacific time, the changelog says:

Tue Oct 06 18:54:57 2009 -0700
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=1db61f2dfded
Tryserver builds will appear in
https://build.mozilla.org/tryserver-builds/hsivonen@iki.fi-try-d85dc3fc569b/

The builds there have patches for bug 514661, bug 515338, bug 516406, bug 482918, bug 482919 and bug 503473 applied. No doubt the builds will have some new flaws introduced by the off-the-main-thread move and speculative parsing, but please test if the changes fix this crash on Windows 7.
If https://build.mozilla.org/tryserver-builds/hsivonen@iki.fi-try-0e5c9333f52b/try-0e5c9333f52b-win32.zip is the right thing, I have not got it to crash so far.
At least I did got to twitter.com and some others without crashing...

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre Firefox/3.5.3 ID:20091014235748
Thanks for the link; I'm trying it, and have not gotten any Windows 7 specific crashes - that said, it -did- crash when I tried to look at my e-mails in Hotmail, but it also did this on my laptop running Windows Vista so this seems to be a different (HTML5-related) bug. Still a bit of a show-stopper though, so I hope that gets resolved soon.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre
(In reply to comment #19)
> If
> https://build.mozilla.org/tryserver-builds/hsivonen@iki.fi-try-0e5c9333f52b/try-0e5c9333f52b-win32.zip
> is the right thing, I have not got it to crash so far.
> At least I did got to twitter.com and some others without crashing...

Thanks. Yes, that's the right build. The previous attempt failed to build on Windows.

I'm marking this bug as dependent on bug 503473, since this crash (like a number of others) goes away when the whole patch queue up to and including bug 503473 is applied.
Depends on: 503473
Getting this crash at random times on bugzilla.mozilla.org now when clicking on links to bug reports...

http://crash-stats.mozilla.com/report/index/c0d766d1-2e19-4f4f-9d8f-72f242091015
http://crash-stats.mozilla.com/report/index/b5949a21-5d0f-4f24-88f0-91c532091015
I'm using Minefield hourly build 20091018154109 and I have html5=true and I'm not crashing on twitter.com.
Using Minefield nightly build 20091019043323 and I have html5.enable=true and I'm still not crashing on Twitter.  I'm not sure what landed to make this crash go away, but I'm happy it did.
This is resolved as far as I am concerned. If someone wants to re-open this for whatever reason, feel free, but html5=enabled is no longer crashing on Twitter.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@nsHtml5TreeOpExecutor::ExecuteScript() ]
You need to log in before you can comment on or make changes to this bug.