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)

x86
Linux
defect

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.
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.
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
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>
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...
That's OK for the test... if it's served as text/html, it won't be treated as
anything stricter than strict...
I assumed you did that on purpose; I does prove that the strict DTD get's kicked 
to handle this broken but potential case.
Rick: Um, how does that test work? What would you get in strict mode and what 
would you get in quirks mode?
Adding crash keyword
Keywords: crash
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
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.
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.
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 → ---
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
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
*** Bug 40004 has been marked as a duplicate of this bug. ***
Rickg, please make sure to test bug 40004.
*** Bug 39343 has been marked as a duplicate of this bug. ***
*** Bug 27507 has been marked as a duplicate of this bug. ***
*** Bug 38158 has been marked as a duplicate of this bug. ***
*** Bug 40422 has been marked as a duplicate of this bug. ***
Fixed by change to doctype handling code.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
*** Bug 39195 has been marked as a duplicate of this bug. ***
I still have these problems: I vote for REOPENING

This is with 2000-05-25-08 and the checking was 2000-05-24-23.

> 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!
*** Bug 40145 has been marked as a duplicate of this bug. ***
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 → ---
The crash in 40145 is related to entities in XUL, not XHTML served as text/html.
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 ago24 years ago
Resolution: --- → FIXED
> 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
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
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.