Closed
Bug 39520
Opened 24 years ago
Closed 24 years ago
crash on XHTML pages served as text/html
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: dbaron, Assigned: rickg)
References
()
Details
(Keywords: crash, Whiteboard: [nsbeta2+])
DESCRIPTION: I'm reliably crashing on the XHTML page in the URLbar above (served as text/html). (Note the link may not work right due to bug 39281.) I see the following stack trace: #0 0x4148bde6 in HTMLContentSink::CreateContentObject ( this=0x89b8650, aNode=@0xbfffefc8, aNodeType=eHTMLTag_parsererror, aForm=0x0, aWebShell=0x0, aResult=0xbfffef70) at nsHTMLContentSink.cpp:1061 #1 0x4148d012 in SinkContext::OpenContainer ( this=0x82d87d0, aNode=@0xbfffefc8) at nsHTMLContentSink.cpp:1356 #2 0x41492670 in HTMLContentSink::OpenContainer ( this=0x89b8650, aNode=@0xbfffefc8) at nsHTMLContentSink.cpp:3015 #3 0x4190bc80 in CWellFormedDTD::HandleStartToken ( this=0x8358148, aToken=0x87119c0) at nsWellFormedDTD.cpp:616 #4 0x4190be8c in CWellFormedDTD::HandleErrorToken ( this=0x8358148, aToken=0x8354af0) at nsWellFormedDTD.cpp:676 #5 0x4190b86e in CWellFormedDTD::HandleToken ( this=0x8358148, aToken=0x8354af0, aParser=0x8a1ef38) at nsWellFormedDTD.cpp:505 #6 0x4190b400 in CWellFormedDTD::BuildModel ( this=0x8358148, aParser=0x8a1ef38, aTokenizer=0x89b6348, anObserver=0x0, aSink=0x89b8650) at nsWellFormedDTD.cpp:257 #7 0x418fddbf in nsParser::BuildModel (this=0x8a1ef38) at nsParser.cpp:1805 #8 0x418fdb55 in nsParser::ResumeParse (this=0x8a1ef38, allowIteration=1, aIsFinalChunk=0) at nsParser.cpp:1689 #9 0x418fe8ba in nsParser::OnDataAvailable ( this=0x8a1ef38, channel=0x82bb2b0, aContext=0x0, pIStream=0x87a87c4, sourceOffset=0, aLength=1323) at nsParser.cpp:2123 #10 0x40f94b89 in nsDocumentOpenInfo::OnDataAvailable ( this=0x87d1128, aChannel=0x82bb2b0, aCtxt=0x0, inStr=0x87a87c4, sourceOffset=0, count=1323) at nsURILoader.cpp:189 ... On the page http://www.fas.harvard.edu/~dbaron/www/xml/valtest.html (also XHTML served as text/html), I see the stack trace: #0 0x405a38a7 in memcpy (dstpp=0x873a868, srcpp=0x0, len=4096) at ../sysdeps/generic/memcpy.c:55 #1 0x400f725b in nsByteArrayInputStream::Read ( this=0x86db6a0, aBuffer=0x873a868 "<?xml version=\"1.0\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/WD-html-in-xml/DTD/xhtml1-transitional.dtd\">\n<html lang=\"en-US\" xmlns=\"http://www.w3.org/Prof"..., aCount=4096, aNumRead=0xbffff0fc) at nsByteArrayInputStream.cpp:72 #2 0x418fe71e in nsParser::OnDataAvailable ( this=0x81c9dd8, channel=0x86d93d0, aContext=0x0, pIStream=0x86db6a0, sourceOffset=0, aLength=4096) at nsParser.cpp:2072 #3 0x40f94b89 in ?? () from /home/david/mozilla/src/mozilla/dist/bin/components/liburiloader.so #4 0x40e9b9bc in nsHTTPFinalListener::OnDataAvailable ( this=0x86d9558, aChannel=0x86d93d0, aContext=0x0, aStream=0x86db6a0, aSourceOffset=0, aCount=4096) at nsHTTPResponseListener.cpp:1216 #5 0x40e659bb in nsHTTPChunkConv::OnDataAvailable ( this=0x8737f18, aChannel=0x86d93d0, aContext=0x0, iStr=0x875e6b4, aSourceOffset=0, aCount=1422) at nsHTTPChunkConv.cpp:208 #6 0x40e99f41 in nsHTTPServerListener::OnDataAvailable ( this=0x86d8b70, channel=0x86dbc7c, context=0x86d93d0, i_pStream=0x875e6b4, i_SourceOffset=2920, i_Length=1422) at nsHTTPResponseListener.cpp:540 #7 0x40e3957f in nsOnDataAvailableEvent::HandleEvent ( this=0x8604278) at nsAsyncStreamListener.cpp:406 #8 0x40e38807 in nsStreamListenerEvent::HandlePLEvent ( aEvent=0x8768448) at nsAsyncStreamListener.cpp:97 #9 0x4010de2e in PL_HandleEvent (self=0x8768448) at plevent.c:575 #10 0x4010dcdc in PL_ProcessPendingEvents ( self=0x8124b08) at plevent.c:520 #11 0x4010f980 in nsEventQueueImpl::ProcessPendingEvents (this=0x80f9988) at nsEventQueue.cpp:316 ... although I managed once to "load" the latter page without crashing (but got the symptoms below). On some other XHTML pages, instead of crashing, I get the assertion: ###!!! ASSERTION: NS_ENSURE_TRUE(aName.Length()) failed: 'aName.Length()', file nsNodeInfoManager.cpp, line 155 ###!!! Break: at file nsNodeInfoManager.cpp, line 155 and then nothing displays. DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-05-16-08-M16 release build * Linux, mozilla, my tree, 2000-05-16, with most patches before tree reopen I'll see if I can boil this down to a simpler testcase.
Reporter | ||
Comment 1•24 years ago
|
||
After loading http://www.people.fas.harvard.edu/~dbaron/tmp/xhtml.html, a much simpler page, the page "loaded" (with the above assertion), displayed nothing, and then crashed when I tried to exit: #0 0x402a363f in __pthread_getspecific (key=0) at specific.c:117 #1 0x402884a6 in PR_GetCurrentThread () at ptthread.c:558 #2 0x40119094 in NS_CurrentThread () at nsDebug.cpp:404 #3 0x40119108 in NS_CheckThreadSafe ( owningThread=0x805f678, msg=0x41947da6 "nsParser not thread-safe") at nsDebug.cpp:427 #4 0x418fb569 in nsParser::Release (this=0x8603e78) at nsParser.cpp:253 #5 0x4148f9ef in HTMLContentSink::~HTMLContentSink ( this=0x86cd578, __in_chrg=3) at nsHTMLContentSink.cpp:2189 #6 0x4148fe84 in HTMLContentSink::Release ( this=0x86cd578) at nsHTMLContentSink.cpp:2237 #7 0x418fb3ac in nsParser::~nsParser (this=0x8603e78, __in_chrg=3) at nsParser.cpp:240 #8 0x418fb5a2 in nsParser::Release (this=0x8603e78) at nsParser.cpp:253 ... #1457 0x4148f9ef in HTMLContentSink::~HTMLContentSink ( this=0x86cd578, __in_chrg=3) at nsHTMLContentSink.cpp:2189 #1458 0x4148fe84 in HTMLContentSink::Release ( this=0x86cd578) at nsHTMLContentSink.cpp:2237 #1459 0x418fb3ac in nsParser::~nsParser (this=0x8603e78, __in_chrg=3) at nsParser.cpp:240 #1460 0x418fb5a2 in nsParser::Release (this=0x8603e78) at nsParser.cpp:253 #1461 0x4148f9ef in HTMLContentSink::~HTMLContentSink ( this=0x86cd578, __in_chrg=3) at nsHTMLContentSink.cpp:2189 ... (is gdb confused??? I'm giving up on hitting Enter to see the end of this thing.)
David: XHTML as text/html should be treated as strict html, so make sure you've enabled the strict DTD. (This is done by setting ENABLE_STRICT=true in your environment). Second -- the document is badly formed, so you won't see much with the strict DTD unless you add the <html>, <head> and <body> tags.
Err, sorry, the <html>, <body> and <head> tags are in fact optional. I'll update the DTD accordingly.
Comment 4•24 years ago
|
||
win98 too, suggest OS: All
The <head> <html> and <body> tags are now all optional in my tree; awaiting chance to land. With these changes, this page is laid out reasonably well. Can you explain how your Table Inherit Test and ColSpan Background Test's are supposed to work?
Status: NEW → ASSIGNED
Reporter | ||
Comment 6•24 years ago
|
||
They use two things in layout that depend on the quirks mode to figure out which mode is being used. Colors and fonts (both?) don't inherit into tables (to emulate older browsers) and colspan backgrounds are not drawn in quirks mode. It's actually Ian's test page, although I came up with the colspan test. Do these changes fix all the crashes? Or is the strict DTD still a bit buggy?
Well, the DTD is brand new, so I expect more bugs. But it's getting better *very* quickly. I'll land this set of changes today (I hope). FYI: I think this makes a better mode test: <h2>Mode</h2> <table><td><p style="color:red">You are in compatability mode.</p></td></table> <table><tr><td><p style="color:green">You are in standard/strict mode.</p></td></table>
Comment 8•24 years ago
|
||
Um, actually, I just realised that marking that page as being XHTML is rather silly since the page is not valid XML. It's valid HTML 4 Strict, but not XHTML. I'm not going to be doing anything about this...
Reporter | ||
Comment 9•24 years ago
|
||
That's OK for the test... if it's served as text/html, it won't be treated as anything stricter than strict...
Assignee | ||
Comment 10•24 years ago
|
||
I assumed you did that on purpose; I does prove that the strict DTD get's kicked to handle this broken but potential case.
Comment 11•24 years ago
|
||
Rick: Um, how does that test work? What would you get in strict mode and what would you get in quirks mode?
Assignee | ||
Comment 13•24 years ago
|
||
Ian: the point is that we were given text/html (even with a bogus doctype), and still tried to make sense of it. In this case, we kicked into the most strict HTML dtd we could. That's a pretty reasonable answer. The rest of these issues have been addressed with my last checkin.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 14•24 years ago
|
||
If mozilla has any features that try to guess at document types, or otherwise let broken pages slide, I would like a 'strict adherance' option somewhere in the preferances. This would probably break many pages, but would be *GREAT* for testing your own code out on. Also, maybe an optional setting for a warning dialog to pop up on a page-by-page basis, telling you the page is broken, and asking if you'd like to try to decipher it with 'quirks mode', i think someone called it. I'm not filing this as a supperate RFE as I'm not sure if this isn't already done/can be done/should be done. Thought I'd run it by here first, since this bug is what gave me the idea.
Reporter | ||
Comment 15•24 years ago
|
||
BTW, I haven't enabled the strict DTD. For some reason I thought it was used by default in strict mode now, but I guess not. So all the comments on this bug (about the crash) are when I was not using it.
Reporter | ||
Comment 16•24 years ago
|
||
Reopening. I'm still seeing the crash in a build I pulled today, WITHOUT the environment variable to enable the strict DTD. (The page works fine with the strict DTD enabled by environment variable, but that isn't the default yet.) I'm still seeing the first stack trace above (I haven't tried the others).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 17•24 years ago
|
||
The crash is caused can be traced back to the fact that you're given me an invalid XML document and an HTML mimetype. I'll add code to detect and correct.
Status: REOPENED → ASSIGNED
Comment 19•24 years ago
|
||
*** Bug 40004 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Rickg, please make sure to test bug 40004.
Comment 21•24 years ago
|
||
*** Bug 39343 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 27507 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
*** Bug 38158 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
*** Bug 40422 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 25•24 years ago
|
||
Fixed by change to doctype handling code.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 26•24 years ago
|
||
*** Bug 39195 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
I still have these problems: I vote for REOPENING This is with 2000-05-25-08 and the checking was 2000-05-24-23.
Comment 28•24 years ago
|
||
> This is with 2000-05-25-08 and the checking was 2000-05-24-23.
Rewording: The tested snapshot is from 2000-05-25-08 whereas the CVS checkin was
around 2000-05-24-23. Please reopen!
Comment 29•24 years ago
|
||
*** Bug 40145 has been marked as a duplicate of this bug. ***
Comment 30•24 years ago
|
||
Reopening. Bug 40145 (which I marked duplicate of this one) has the same stack trace and is still alive in build 2000052508 on PC/Linux. It has a reproducible testcase (an attachment that crashes when saved locally and then loaded from file). CC owner of that bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 31•24 years ago
|
||
The crash in 40145 is related to entities in XUL, not XHTML served as text/html.
Assignee | ||
Comment 32•24 years ago
|
||
Tobias: I can't duplicate this problem, so I'd be greatful if you would open a new bug with a specific reduced testcase that crashes for you. I'm marking this case (and it's list of erroneous dups) fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 33•24 years ago
|
||
> I can't duplicate this problem, so I'd be greatful if you would open a > new bug with a specific reduced testcase that crashes for you. Ok, I reopen Bug 39195
Comment 34•24 years ago
|
||
Verified 2000-07-07-10-M17 : Linux 2000-07-07-10-M17 : WinNT 2000-07-07-10-M17 : Win98 2000-07-05-10-M17 : Mac
Status: RESOLVED → VERIFIED
Comment 35•24 years ago
|
||
Adding keyword to bugs which already show a nsbeta2 triage value in the status whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
You need to log in
before you can comment on or make changes to this bug.
Description
•