Closed Bug 159168 Opened 22 years ago Closed 22 years ago

Mozilla 1.1b fataly crashes various dlls (including GKLAYOUT.DLL) when validating non-html files/URLs with W3C HTML-Validator

Categories

(SeaMonkey :: General, defect)

x86
Windows 98
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 158796

People

(Reporter: webmaster, Assigned: Matti)

References

()

Details

(Keywords: crash, Whiteboard: TestcaseWanted)

Attachments

(1 file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020722 BuildID: 2002072204 When I use the W3C-Validator found on http://validator.w3.org/ to validate specific URLs Mozilla crashes and I receive a message that GKLayout.dll caused this error on my Win98 machine. This doesn't happend with every page I validate. The only page I found out so far is: http://www.chip.de When I try to validate this url, Mozilla posts the data but hangs after 2/3 and crashes. I won't see the normal page with the non-standard html code notes etc. I can reproduce this behaviour with this website. Other urls work. Reproducible: Always Steps to Reproduce: 1. open http://validator.w3.org 2. enter url for validation: http://www.chip.de 3. wait for the crash during request is processed Actual Results: Mozilla 1.1b 2002072204 crashes Error is reported in GKLayout.dll Have to restart Mozilla, but actually doesn't solve the problem as bug can be reproduced. Expected Results: It should display the web page that you expect when using the w3c validator with any other website... gklayout.dll crashes
Keywords: crash
Reporter: Can you please add a talkback ID from that crash ? (Use a talkback enabled build and after talkback submitted the crash run mozilla/components/talkback to get the ID)
Actually I tried it several times with the www.chip.de for validation purposes... The crash can affect various dlls. Sometimes no dll can be specified. Recently I encountered a Windows "bluescreen" with vxd warning in connection with a kernel32.dll fault... Hope you can fix this one!
Okay... The Talkback IDs of this crash/hang (submitted twice) are: TB8634947Z TB8634886Z
I can confirm this. Using Nightly 2002071708 on Windows NT (apparently its not a recent regression). Talkback ID: TB8636034M Suggest STATUS: NEW
Summary: Mozilla 1.1b fataly crashes GKLAYOUT.DLL when validating a specific URL with W3C HTML-Validator → Mozilla 1.1b fataly crashes various dlls (including GKLAYOUT.DLL) when validating a specific URL with W3C HTML-Validator
Confirmed on WinXP trunk build 2002072308
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: stackwanted
Whiteboard: Need TB8636034M data
Possibly a crash related to BiDiUtils. cc'ing Simon. Though I don't see any BiDi text on www.chip.de Incident #8636034 ------------------ Product ID MozillaTrunk Build ID 2002070908 Operating System Windows NT 4.0 build 1381 URL visited http://validator.w3.org User Comments Running W3C HTML validator against http://www.chip.de This is Mozilla bug 159168. Mozilla 2002071708 nightly Stack Trace Conv_FE_06_WithReverse [c:/builds/seamonkey/mozilla/content/shared/src/nsBidiUtils.cpp, line 400] 0xfffd0000
Keywords: stackwanted
Whiteboard: Need TB8636034M data
I just tried to reproduce this bug with my Netscape 6.21: "About" says: Mozilla/5.0 (Windows; U; Win98; de-DE; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 Actually there is no crash this time! But when the new page is build I can only see lot's of "nonsense" characters in the validator's debug lines/notes instead of the html source code. So not really what you should expect. Tried to compensate by deliberatly choosing a character encoding and/or doctype. But it won't help. Different "nonsense" characters displayed but not any better. I guess it might have something to do with the index.html on this webpage because the whole document seems to be stored in just a few! lines without lot's of carriage returns in it. At leasts that's what I noticed. Maybe some kind of buffer overflow occurs when processing such a long input stream?! Of course, that's just an vague idea!
http://www.chip.de returns a gzipped page. These are the HTTP headers: HTTP/1.0 200 OK Date: Wed, 24 Jul 2002 21:24:55 GMT Cache-Control: max-age=900 Expires: Wed, 24 Jul 2002 21:39:55 GMT Content-Type: text/html Content-Encoding: gzip Content-Length: 11207 The crash looks similar to that in bug 158796. Reporter: what is your setting in Edit | Preferences | Navigator | Languages | Default Character Coding?
Simon: I can reproduce this also with my optimized trunk build (Iso8859-15) but not with my debug build.
argh, sorry for this : I crashed with my normal working profile and this profile has nothing (empty) in the "Default Character Coding" box. I have "Iso-8859-1" under View/Character Encoding selected
I also use: Iso-8859-1
I tried to test this with the patch from bug 158796 but today http://www.chip.de is no longer gzipped. Even if that patch prevents the crash there is another bug lurking here, because we should never go through ArabicShaping or Conv_FE_06_WithReverse in an ISO-8859-1 page (unless there are NCRs). Therefore I hesitate to resolve this as WORKSFORME too hastily, and if we can find another testcase or simulate the original I would like to go on testing.
Whiteboard: TestcaseWanted
Simon: I crash if i enter the attachment URL in the validator !
Okay folks, take this... Upload any! file with the validator and let Mozilla crash. I took "attrib.exe" from my Windows installation and then I tried "Mozilla.exe" You can crash the browser with almost everything which isn't html, I guess...
Summary: Mozilla 1.1b fataly crashes various dlls (including GKLAYOUT.DLL) when validating a specific URL with W3C HTML-Validator → Mozilla 1.1b fataly crashes various dlls (including GKLAYOUT.DLL) when validating non-html files/URLs with W3C HTML-Validator
What if you just load a binary file from the URLbar?
wfm with the patch in bug 158796
I also had this scary idea that somethings really wrong with the parser. But actually renaming a binary file to html and loading it won't work/crash. Tried to add some <html> around the binary, no change. I also tried to validate a binary with a different browser (IE) and saved the resulting html file to my webspace. But loading (renamed) html files with weird content via the url locationbar doesn't cause a crash. Suggest that it'll be useful to get the w3c.org's validation script or it's output before it's sent back to the browser.
this is a dupe of bug 158796. Thanks Simon for the analysis and the patch ! *** This bug has been marked as a duplicate of 158796 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You can see the raw output of the validator by going to http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fvalidator.w3.org%2Fcheck%3Furi%3Dhttp%253A%252F%252Fbugzilla.mozilla.org%252Fattachment.cgi%253Fid%253D92749%2526action%253Dview%26charset%3D%2528detect%2Bautomatically%2529%26doctype%3DInline A little analysis of that shows that the validator is sending back an UTF-8 page, but has not converted the input in the source listing to UTF-8, so we get random characters when converting back from UTF-8.
Amusingly enough, if I feed the validator's output back at itself, it says "Sorry, I am unable to validate this document because on lines 111, 117, 123, <snip> 322, 323, 324, 325, 326, 327, 328 it contained some byte(s) that I cannot interpret as utf-8. Please check both the content of the file and the character encoding indication." http://validator.w3.org/check?uri=http%3A%2F%2Fvalidator.w3.org%2Fcheck%3Furi%3Dhttp%253A%252F%252Fbugzilla.mozilla.org%252Fattachment.cgi%253Fid%253D92749%2526action%253Dview%26charset%3D%2528detect%2Bautomatically%2529%26doctype%3DInline&charset=%28detect+automatically%29&doctype=Inline
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: