Closed Bug 489322 Opened 15 years ago Closed 15 years ago

3.0.10 pre crashes with HTML validator when viewing source [@ @0x0 | nsTextFrame::ClearTextRun() ]

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
1.9.0 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mgueury, Assigned: dholbert)

References

(
URL
)

Details

(6 keywords)

Crash Data

Attachments

(1 file)

reduced testcase
17 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10pre) Gecko/2009042005 GranParadiso/3.0.10pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10pre) Gecko/2009042005 GranParadiso/3.0.10pre

On Windows, I got reports from 2 users using the HTML Validator extension with the 3.0.10pre.  With this version, and it seems with 3.0.8 pre and 3.0.9 pre, Firefox crashes when viewing the pages source.

I am the extension author.

Such problem does not happen with production builds (yet).

Reproducible: Always

Steps to Reproduce:
1. Download ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla1.9.0/firefox-3.0.10pre.en-US.win32.zip
and unzip the file.
2. Start Firefox 
3. Install the HTML validator (the version is not really important) 0.855 here
   http://users.skynet.be/mgueury/mozilla/download.html
4. restart Firefox
5. Go to www.google.com
6; View Source -> crash
Actual Results:  
Crash

Expected Results:  
No crash

It is happening only in pre build ? 

After debugging the tidySource.js file.
I found that it crashes when putting a color on the lines of the HTML source where there is a HTML error.

The procedure is called - colorizeLines.
The way this procedure works is that it changes the DOM of the HTML source of the HTML...

Workaround
----------
There is an option in the HTML validator to disable it :
- Options 
  - Hightlight lines with errors.

When uncheked it works again, meaning that the problem is well in the DOM javascript API used by colorizeLines
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10pre) Gecko/2009042105 GranParadiso/3.0.10pre

http://crash-stats.mozilla.com/report/index/7123be51-c9f0-465f-a18f-8535b2090421?p=1
Component: General → Layout
Keywords: crash
Product: Firefox → Core
QA Contact: general → layout
Summary: 3.0.10 pre crahes with HTML validator when viewing source → 3.0.10 pre crahes with HTML validator when viewing source [@ @0x0 | nsTextFrame::ClearTextRun() ]
Version: unspecified → 1.9.0 Branch
0  	 	@0x0  	
1 	xul.dll 	nsTextFrame::ClearTextRun 	mozilla/layout/generic/nsTextFrameThebes.cpp:3503
2 	xul.dll 	BuildTextRunsScanner::AssignTextRun 	mozilla/layout/generic/nsTextFrameThebes.cpp:1835
3 	xul.dll 	BuildTextRunsScanner::BuildTextRunForFrames 	mozilla/layout/generic/nsTextFrameThebes.cpp:1716
4 	xul.dll 	BuildTextRunsScanner::FlushFrames 	mozilla/layout/generic/nsTextFrameThebes.cpp:1119
5 	xul.dll 	xul.dll@0x2c1bcb 	
6 	xul.dll 	xul.dll@0x2c1c54 	
7 	xul.dll 	xul.dll@0x2c1c54 	
8 	xul.dll 	BuildTextRuns 	mozilla/layout/generic/nsTextFrameThebes.cpp:1036
9 	xul.dll 	nsTextFrame::EnsureTextRun 	mozilla/layout/generic/nsTextFrameThebes.cpp:1859
10 	xul.dll 	nsTextFrame::Reflow 	mozilla/layout/generic/nsTextFrameThebes.cpp:5535
11 	xul.dll 	nsLineLayout::ReflowFrame 	mozilla/layout/generic/nsLineLayout.cpp:859
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.0.10?
Marc Gueury,

I use your excellent extension and I now believe that my bug 489509 may be in fact a DUPlicate of this bug 489322.

Adding crashreportid keyword

regards, Gérard
Keywords: crashreportid
> It is happening only in pre build ? 

When following the steps to reproduce you provided with Firefox 3.0.9 rv:1.9.0.9 build 2009040821 (XP Pro SP3 here), I crashed (see bug 489509 for more info on this).

Using View/source view (Ctrl+U) will not crash on any/all webpages: like you say, the webpage must have errors and hightlight lines with errors option should be checked.

regards, Gérard
Firefox 3.0.9 downloaded in the background and installed when I restarted. Ordinarily I think that is a brilliant thing, but this time, because of this bug, it's corrupting my ability to work.

Confirmation crash reports:

http://crash-stats.mozilla.com/report/index/e5e76111-98f2-4785-9fe6-ba0582090421
http://crash-stats.mozilla.com/report/index/49a91d2b-b49c-4316-957e-d2c9b2090421
http://crash-stats.mozilla.com/report/index/87a98e87-4982-488f-8c11-6a2c72090421
http://crash-stats.mozilla.com/report/index/68ed2a47-4f54-4196-bdbb-2e2782090421

I installed the latest 0.8.5.5 version from the author's site because it's newer than the AMO version (typical) however this also caused the same crash.
Confirmed with Firefox 3.0.9 and HTML Validator 0.8.5.2 & 0.8.5.5
When viewing source, application crashes.
Need a regression range here...

Rey: Do we have contacts with the HTML Validator team? We should probably work with them on a workaround since 3.0.10 won't be for another month.
Keywords: qawanted, regression, regressionwindow-wanted
Sam, the originator of this bug is the add-on's author. His name is Marc Gueury.
I am the extension author. I am sorry but I am quite lost in what to do to avoid the flood of mails I get...

This code that cause problems in the extension was working from
Firefox 1.0 until 3.0.8. And unhappily, 3.0.9 crashes as well as 3.0.10 pre.... 

The bug is not in my side and the only thing I can do is to disable
the highlighting of the lines with HTML errors :/

Without better solution and due to the urgency, I have released on my website As well as on addons.mozilla.org a version 0.856 that disables this feature. 

Unhappily, 0.856 is not reviewed yet in addons.mozilla.org:
> https://addons.mozilla.org/en-US/firefox/addon/249

DO YOU KNOW A WAY TO SPEED THE REVIEW ? 

Thanks a lot,

Marc
I first found this behavior in version 3.0.8pre, maybe this information helps to track down the bug.

Markus
Summary: 3.0.10 pre crahes with HTML validator when viewing source [@ @0x0 | nsTextFrame::ClearTextRun() ] → 3.0.10 pre crashes with HTML validator when viewing source [@ @0x0 | nsTextFrame::ClearTextRun() ]
If somebody does a binary search of nightly builds (look in the directories ending in "-mozilla1.9.0" in the month subdirectories of http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/ ) to figure out which day the problem started, that would be likely to help.  If you do this... say (1) what platform you were testing, (2) which build was the last one without the problem, and (3) which build was the first one with the problem.  (And, if you want to be even more precise, you can give the SourceStamp line from the application.ini file along with (2) and (3).)
3.0.8pre became 3.0.9... There weren't really "pre" builds of what became the
actual 3.0.8 release, it was an emergency release based off the 3.0.7 release
with a couple of fixes. The "3.0.8" we were working on was renamed to 3.0.9 to
make room for that release.

But that does pin the time frame down to before the rename.
It's a new topcrash, too. Hard to believe all those people are using HTML Validator.

http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0.9
Keywords: topcrash
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.10?
Flags: blocking1.9.0.10+
@Daniel Veditz - HTML Tidy it's the best thing created for webmasters!
thanks Marc Gueury, but you really need to solve this thing, I'll turn back to 3.0.8, i can't even browse a website without that addon ....
I haven't gone back for a full regression range yet, but I'd guess bug 431260 or bug 444027, both of which landed in the cycle. If someone can verify by checking the February 26 build to the February 27 build, that'd be great.
Flags: blocking1.9.0.10+ → blocking1.9.0.10?
I'm looking...
(In reply to comment #10)
> ...Without better solution and due to the urgency, I have released on my website
> As well as on addons.mozilla.org a version 0.856 that disables this feature. 
> 
> Unhappily, 0.856 is not reviewed yet in addons.mozilla.org:
> > https://addons.mozilla.org/en-US/firefox/addon/249
> 
> DO YOU KNOW A WAY TO SPEED THE REVIEW ? 
> 
> Thanks a lot,
> 
> Marc

I've pushed your update through.
I have chosen to downgrade Firefox, i prefer having HTML Validator rather than FF 3.0.9.  Hope u solve this soon. THX!
(In reply to comment #16)
> I haven't gone back for a full regression range yet, but I'd guess bug 431260
> or bug 444027, both of which landed in the cycle. If someone can verify by
> checking the February 26 build to the February 27 build, that'd be great.

That range is indeed true.
Keywords: regressionwindow-wanted
Andrei, if you get the new version of the validator, it doesn't crash...

Sam,

Doesn't crash in  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8pre) Gecko/2009022606 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).

Crashes in  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8pre) Gecko/2009022606 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).
Er... it crashes in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8pre) Gecko/2009022706 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).

Bad clipboard.
Flags: in-testsuite?
Flags: blocking1.9.0.10? → blocking1.9.0.10+
mgueury: can you extract the code from tidySource.js into a testcase which crashes by itself?
I can't reproduce this in a debug build on Linux, but I *can* reproduce it 100% reliably in an optimized build. (using HTML Validator version 0.8.5.4 from the download URL in comment 0)

I tried viewing source of google.com and also the default Firefox start pages, http://www.mozilla.org/projects/granparadiso/ and http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official

Crash reports links below.  They're all crashes at random addresses while inside of nsTextFrame::ClearTextRun() (usually 0xaf******).  In the third Firefox3.0.9 crash below, the random address actually appears to map to an address in one of my font files, "DejaVuSans-Bold.ttf@0x61f1e".

Firefox 3.0.9:
http://crash-stats.mozilla.com/report/index/fd3456ab-156f-49ee-9c6b-6335b2090422
http://crash-stats.mozilla.com/report/index/496f027f-9da2-4625-8f57-277fb2090422
http://crash-stats.mozilla.com/report/index/d72d8155-fd20-4115-a953-d49b72090422
http://crash-stats.mozilla.com/report/index/8d9cda89-7271-423b-9c05-41a3c2090422

latest-mozilla1.9.0 nightly:
http://crash-stats.mozilla.com/report/index/abf58b09-875d-49a5-af71-c702d2090422
http://crash-stats.mozilla.com/report/index/f01ade56-4b67-4932-956b-5089f2090422

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009040820 Firefox/3.0.9
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10pre) Gecko/2009042204 GranParadiso/3.0.10pre
OS: Windows XP → All
Firefox updated itself to 3.0.9 and i had to get new version. I don't notice any diffrence though..
FWIW, I think we have a fix for this in bug 489647.  Stay tuned...
Attached file reduced testcase — 
Here's a reduced testcase that reproduces the bug under Linux, when doing a View-Source with HTML Validator 0.854 installed in Firefox 3.0.9.
@Daniel Holbert - oh yea .... more restricted pages ... :|
Assigning this to dholbert since he has a fix.
Assignee: nobody → dholbert
This will be fixed in a soon-coming Firefox 3.0.10 release.
Flags: blocking1.9.0.10+
The fix in bug 489647 has landed.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.0.10, fixed1.9.0.11
Resolution: --- → FIXED
This turned out to be a regression from bug 431260
Blocks: 431260
Depends on: CVE-2009-1313
Sweet! So this will be in 3.0.10?
Keywords: qawanted
Hardware: x86 → All
Verified fixed on Linux in 1.9.0.10 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10. 

I will mark it verified1.9.0.10 when I can check on Windows as well.
Checked on Windows with version Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

Validator version 0.8.5.2 since in 0.8.5.6 the "mark line" feature seems to be completely disabled although there is a check box...

All clear ;-)
Verified on Windows XP: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729).
Keywords: fixed1.9.0.10 → verified1.9.0.10
Marc: This problem is now fixed in Firefox 3.0.10, which is being released today, specifically for this crash. It typically takes 5-8 days for the bulk of Firefox users to upgrade. You can probably return your extension to the normal, fully functional version in a few days. Thanks for reporting the problem!
Thanks a lot your work. I will release a new version re-enabling the line highlighting in the next days.
Hey ... common Marc, the 3.0.10 it has been released. Why don't you make the update? I downgraded to 0.855 and everything works fine :) you should to the same
Verified for 1.9.0.11 as well with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11pre) Gecko/2009051404 GranParadiso/3.0.11pre.
Keywords: fixed1.9.0.11 → verified1.9.0.11
Crash Signature: [@ @0x0 | nsTextFrame::ClearTextRun() ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: