Closed
Bug 32201
Opened 24 years ago
Closed 24 years ago
The new layout of wired.com crashes the browser consistently
Categories
(Core :: DOM: HTML Parser, defect, P3)
Core
DOM: HTML Parser
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: sytobinh, Assigned: harishd)
References
()
Details
(Keywords: crash, top100, Whiteboard: [PDT-])
Attachments
(4 files)
Every time I load wired magazine (which redesigned its site in the last 2 hours) the browser crashes immediately. I can't even get far enough to see what is going wrong.
Well, I did some more research, and this is a VERY bizzare bug, at least to my way of thinking. The problem turns out to be in unclosed font tags. The bad html that causes the problem is all at the center of the page, in the article list. It is easy to pick out in the source. Now, this section starts out with 62 <font> tags and only 44 </font> tags. This is 18 unclosed tags, which turns out to be 2 too many. If you close one, or delete one, it still crashes. However, if you delete two, for a total of 16 unclosed font tags, it opens properly. However, I was unable to create a document on my own that had the same behavior, even with FAR more than 16 unclosed tags. I sure hope someone understands this.
|
||
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Updated•24 years ago
|
Assignee: cbegle → karnaze
Component: Browser-General → HTMLTables
Keywords: css1
OS: Linux → All
QA Contact: asadotzler → chrisd
|
|
||
Comment 4•24 years ago
|
||
I think this probably isn't a dup 31137. My stack trace is much different.
This also crashes windows. sytobinh, if you continue to play with this and
manage to make a minimal test case of this it would be really helpful.
Adding CSS tag because its crashing doing getting addrefs in
nsCSSFrameConstructor::ProcessChildren. Further up the stack its doing
stuff in tables.
Changing component to HTMLTables.#1 0x41242d62 in unsigned int
CallQueryInterface<nsIContent> (
aSource=0x8806930, aDestination=0xbfffe1a4)
at ../../../../dist/include/nsISupportsUtils.h:1224
#2 0x41242c70 in nsCOMPtr<nsIContent>::Assert_NoQueryNeeded (this=0xbfffe1e4)
at ../../../../dist/include/nsCOMPtr.h:463
#3 0x41242c20 in nsGetterAddRefs<nsIContent>::~nsGetterAddRefs (
this=0xbfffe1e0, __in_chrg=2) at ../../../../dist/include/nsCOMPtr.h:859
#4 0x410fee0f in nsCSSFrameConstructor::ProcessChildren (this=0x8712608,
aPresShell=0x8712660, aPresContext=0x86d2098, aState=@0xbfffef58,
aContent=0x882cb6c, aFrame=0x88a2034, aCanHaveGeneratedContent=1,
aFrameItems=@0xbfffe23c, aParentIsBlock=1)
at nsCSSFrameConstructor.cpp:9300
#5 0x410ea523 in nsCSSFrameConstructor::ConstructTableCellFrameOnly (
this=0x8712608, aPresShell=0x8712660, aPresContext=0x86d2098,
aState=@0xbfffef58, aContent=0x882cb6c, aParentFrame=0x87eddac,
aStyleContext=0x87f8f70, aNewCellFrame=@0xbfffe3f4,
aNewCellBodyFrame=@0xbfffe440, aTableCreator=@0xbfffe460,
aProcessChildren=1) at nsCSSFrameConstructor.cpp:1880
#6 0x410ea040 in nsCSSFrameConstructor::ConstructTableCellFrame (
this=0x8712608, aPresShell=0x8712660, aPresContext=0x86d2098,
aState=@0xbfffef58, aContent=0x882cb6c, aParentFrame=0x87eddac,
aStyleContext=0x87f8f70, aNewTopFrame=@0xbfffe470,
aNewCellFrame=@0xbfffe3f4, aNewCellBodyFrame=@0xbfffe440,
aTableCreator=@0xbfffe460, aProcessChildren=1)
at nsCSSFrameConstructor.cpp:1794
.... etc|
|
||
Updated•24 years ago
|
Component: HTMLTables → Style System
|
|
||
Comment 6•24 years ago
|
||
|
|
||
Comment 7•24 years ago
|
||
My original crash was from my own build from this afternoon. (on linux) This page crashes m14 as well.
This is not a css or table problem as far as I can tell. The attachment I have submitted crashes mozilla at least 50% of the time on my machine, and larger versions of it crash closer to 100% of the time. Removing the paragraph tags causes the crashing to stop. However, due to variation, I can't really be sure of much.
|
|
||
Comment 10•24 years ago
|
||
I agree that this looks like a dup of 31137. Assigning to parser to put on rickg's radar. Also, this seems to be a linux-only crash after all, although mac and win95 report the page loads a lot slower than in ns 4.x. Putting on PDT+ radar since I don't think we want to ship a beta that crashes on wired.com
|
|
||
Comment 11•24 years ago
|
||
|
|
||
Comment 12•24 years ago
|
||
|
||
Comment 13•24 years ago
|
||
Tip from last night. I go to test case with 17 <p><font> from the attachments
in viewer on Solaris and get this:
ABW: Array bounds write
This is occurring while in:
CNavDTD::OpenTransientStyles(nsHTMLTag) [CNavDTD.cpp:2431]
CNavDTD::OpenContainer(const
nsIParserNode*,nsHTMLTag,int,nsEntryStack*) [CNavDTD.cpp:2867]
CNavDTD::HandleDefaultStartToken(CToken*,nsHTMLTag,nsIParserNode*)
[CNavDTD.cpp:1079]
CNavDTD::HandleStartToken(CToken*) [CNavDTD.cpp:1404]
CNavDTD::HandleToken(CToken*,nsIParser*) [CNavDTD.cpp:767]
CNavDTD::BuildModel(nsIParser*,nsITokenizer*,nsITokenObserver*,nsIContentSink*)
[CNavDTD.cpp:504]
nsParser::BuildModel() [nsParser.cpp:1290]
nsParser::ResumeParse(int,int) [nsParser.cpp:1174]
nsParser::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsParser.cpp:1585]
nsDocumentOpenInfo::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsURILoader.cpp:267]
InterceptStreamListener::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsCachedNetData.cpp:1129]
nsHTTPServerListener::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsHTTPResponseListener.cpp:382]
nsOnDataAvailableEvent::HandleEvent()
[nsAsyncStreamListener.cpp:384]
nsStreamListenerEvent::HandlePLEvent(PLEvent*)
[nsAsyncStreamListener.cpp:97]
PL_HandleEvent [plevent.c:563]
PL_ProcessPendingEvents [plevent.c:508]
nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp:314]
event_processor_callback(void*,int,GdkInputCondition)
[nsAppShell.cpp:141]
our_gdk_io_invoke(_GIOChannel*,GIOCondition,void*)
[nsAppShell.cpp:54]
g_io_unix_dispatch [giounix.c:131]
g_main_dispatch [gmain.c:647]
g_main_iterate [gmain.c:854]
g_main_run [gmain.c:912]
gtk_main [gtkmain.c:475]
nsAppShell::Run() [nsAppShell.cpp:303]
nsNativeViewerApp::Run() [nsGtkMain.cpp:55]
main [nsGtkMain.cpp:173]
_start [crt1.o]
Writing 4 bytes to 0xb698a8 in the heap.
Address 0xb698a8 is 9 bytes past end of a malloc'd block at 0xb697a0 of
256 bytes.
This block was allocated from:
malloc [rtlib.o]
__bUiLtIn_nEw [libxpcom.so]
__builtin_new [rtlib.o]
__bUiLtIn_vEc_nEw [libxpcom.so]
__builtin_vec_new [rtlib.o]
nsEntryStack::EnsureCapacityFor(int,int) [nsDTDUtils.cpp:112]
nsEntryStack::Push(const nsIParserNode*,nsEntryStack*)
[nsDTDUtils.cpp:136]
nsDTDContext::PushStyle(const nsIParserNode*) [nsDTDUtils.cpp:531]
CNavDTD::CloseContainersTo(int,nsHTMLTag,int) [CNavDTD.cpp:3070]
CNavDTD::HandleDefaultStartToken(CToken*,nsHTMLTag,nsIParserNode*)
[CNavDTD.cpp:1061]
CNavDTD::HandleStartToken(CToken*) [CNavDTD.cpp:1404]
CNavDTD::HandleToken(CToken*,nsIParser*) [CNavDTD.cpp:767]
CNavDTD::BuildModel(nsIParser*,nsITokenizer*,nsITokenObserver*,nsIContentSink*)
[CNavDTD.cpp:504]
nsParser::BuildModel() [nsParser.cpp:1290]
nsParser::ResumeParse(int,int) [nsParser.cpp:1174]
nsParser::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsParser.cpp:1585]
nsDocumentOpenInfo::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsURILoader.cpp:267]
InterceptStreamListener::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsCachedNetData.cpp:1129]
nsHTTPServerListener::OnDataAvailable(nsIChannel*,nsISupports*,nsIInputStream*,unsigned
int,unsigned int) [nsHTTPResponseListener.cpp:382]
nsOnDataAvailableEvent::HandleEvent()
[nsAsyncStreamListener.cpp:384]
nsStreamListenerEvent::HandlePLEvent(PLEvent*)
[nsAsyncStreamListener.cpp:97]
PL_HandleEvent [plevent.c:563]
PL_ProcessPendingEvents [plevent.c:508]
nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp:314]
event_processor_callback(void*,int,GdkInputCondition)
[nsAppShell.cpp:141]
our_gdk_io_invoke(_GIOChannel*,GIOCondition,void*)
[nsAppShell.cpp:54]
g_io_unix_dispatch [giounix.c:131]
g_main_dispatch [gmain.c:647]
g_main_iterate [gmain.c:854]
g_main_run [gmain.c:912]
|
|
||
Comment 14•24 years ago
|
||
That same test case also demonstrates some parser leaking action quite well.
|
||
Comment 15•24 years ago
|
||
I had a look at the code at the ABW in bruce's purify log, seems as if that is
the root the problem here, the code where the ABW happens is:
nsTagEntry *theEntry=theStack->mEntries;
for(sindex=0;sindex<theStack->mCount;sindex++){
nsCParserNode* theNode=(nsCParserNode*)theEntry->mNode;
--> theEntry++;
if(1==theNode->mUseCount) {
eHTMLTags theNodeTag=(eHTMLTags)theNode->GetNodeType();
if(gHTMLElements[theNodeTag].CanContain(aChildTag)) {
--> theEntry->mParent=theStack; //we do this too, because this entry
differs from the new one we're
pushing...
result=OpenContainer(theNode,theNodeTag,PR_FALSE,theStack);
and the bug here is the tagEntry++ below the for loop (I think). The case that I
saw in the debugger was that theStack->mCount was 1, which, AFAIK means that
there's only one nsTagEntry in theStack->mEntries, yet the parser does
tagEntry++ and sets the value of tagEntry->mParent. Here tagEntry->mParent can
point anywhere so the result of this is either a crash here or corrupted memory
somewhere, which most likely will lead to a crash somewhere else later on.
This patch fixes the crash and doesn't seem to break anything obvious here, but
I havent done any heavy testing.
Index: src/CNavDTD.cpp
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/CNavDTD.cpp,v
retrieving revision 3.272
diff -u -r3.272 CNavDTD.cpp
--- src/CNavDTD.cpp 2000/03/12 22:21:38 3.272
+++ src/CNavDTD.cpp 2000/03/18 20:19:23
@@ -2424,11 +2424,12 @@
nsTagEntry *theEntry=theStack->mEntries;
for(sindex=0;sindex<theStack->mCount;sindex++){
nsCParserNode* theNode=(nsCParserNode*)theEntry->mNode;
+ nsTagEntry *tmpEntry = theEntry;
theEntry++;
if(1==theNode->mUseCount) {
eHTMLTags theNodeTag=(eHTMLTags)theNode->GetNodeType();
if(gHTMLElements[theNodeTag].CanContain(aChildTag)) {
- theEntry->mParent=theStack; //we do this too, because this
entry differs from the new one we're pushing...
+ tmpEntry->mParent=theStack; //we do this too, because this
entry differs from the new one we're pushing...
result=OpenContainer(theNode,theNodeTag,PR_FALSE,theStack);
}
else {
I really feel this (or some other version of the above) should go in for beta1
since there's no way to tell when or where this will show up...|
|
||
Comment 16•24 years ago
|
||
I just build mozilla from the nscp_beta1_BRANCH and verified it has this problem too.
|
||
Comment 17•24 years ago
|
||
It's not crashing at all for me on any version of windows -- and given the date, I fully expect this to go unresolved in beta1. Thank goodness for beta2.
|
|
||
Comment 18•24 years ago
|
||
rickg: As I said, this crashes linux, not windows. (Or is beta1 windows only?) jst's patch works fine for me. I've run most of the browser buster top 100 as well as all the test cases in mozilla/htmlparser/tests/html/ and didn't crash in layout and didn't notice any layout problems.
|
||
Comment 19•24 years ago
|
||
Has this been checked into the Mozilla tip yet? Does it still need to be reviewed?
|
||
Comment 20•24 years ago
|
||
*** Bug 31312 has been marked as a duplicate of this bug. ***
|
|
||
Comment 21•24 years ago
|
||
QA: when this bug is fixed, please verify against the test case in bug 31312 as well
|
|
||
Comment 22•24 years ago
|
||
jst's patch fixes 31312 for me on linux. (tested with mozilla build of nscp beta branch). Without the patch it crashes.
|
||
Comment 24•24 years ago
|
||
Talk back report from Build 2000-03-20-05-M15-nb1b
Trigger Type: Program Crash
Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11)
Call Stack: (Signature = 0x00000049 79536db3)
0x00000049
operator []()
nsCOMPtr_base::assign_from_helper()
nsTextTransformer::Init()
nsTextFrame::Reflow()
nsLineLayout::ReflowFrame()
nsBlockFrame::ReflowInlineFrame()
nsBlockFrame::DoReflowInlineFrames()
nsBlockFrame::DoReflowInlineFramesAuto()
nsBlockFrame::ReflowInlineFrames()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableCellFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableRowFrame::InitialReflow()
nsTableRowFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableRowGroupFrame::ReflowMappedChildren()
nsTableRowGroupFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableFrame::ResizeReflowPass1()
nsTableFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableOuterFrame::Reflow()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsAreaFrame::Reflow()
nsContainerFrame::ReflowChild()
RootFrame::Reflow()
nsContainerFrame::ReflowChild()
nsScrollPortFrame::Reflow()
nsContainerFrame::ReflowChild()
nsGfxScrollFrameInner::ReflowFrame()
nsGfxScrollFrameInner::ReflowScrollArea()
nsGfxScrollFrame::Reflow()
nsContainerFrame::ReflowChild()
ViewportFrame::Reflow()
nsHTMLReflowCommand::Dispatch()
PresShell::ProcessReflowCommands()
PresShell::ExitReflowLock()
PresShell::ContentAppended()
nsDocument::ContentAppended()
nsHTMLDocument::ContentAppended()
HTMLContentSink::NotifyAppend()
SinkContext::FlushTags()
HTMLContentSink::CloseBody()
CNavDTD::CloseBody()
CNavDTD::CloseContainer()
CNavDTD::CloseContainersTo()
CNavDTD::CloseContainersTo()
CNavDTD::DidBuildModel()
nsParser::DidBuildModel()
nsParser::ResumeParse()
nsParser::OnStopRequest()
nsDocumentOpenInfo::OnStopRequest()
InterceptStreamListener::OnStopRequest()
nsHTTPChannel::ResponseCompleted()
nsHTTPServerListener::OnStopRequest()
nsOnStopRequestEvent::HandleEvent()
nsStreamListenerEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xe3ca (0x406203ca)
libglib-1.2.so.0 + 0xfa86 (0x40621a86)
libglib-1.2.so.0 + 0x10041 (0x40622041)
libglib-1.2.so.0 + 0x101e1 (0x406221e1)
libgtk-1.2.so.0 + 0x8b7a9 (0x4054e7a9)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x17cb3 (0x4030fcb3)
|
||
Comment 25•24 years ago
|
||
here's a talkback report from using 2000.03.20.06-M15-nb1b (beta1 branch, opt comm) on linux. not a problem on winNT or mac w/same builds, so added pp keyword. interestingly/strangely, this differs from prassanna's stack info... h'm. http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=47&cp=2&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=7197236 Trigger Type: Program Crash Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Call Stack: (Signature = 0x00000000 895c0ded) 0x00000000 ChildAt() nsCSSFrameConstructor::ProcessBlockChildren() nsCSSFrameConstructor::ConstructBlock() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::ProcessChildren() nsCSSFrameConstructor::ConstructTableCellFrameOnly() nsCSSFrameConstructor::ConstructTableCellFrame() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableRowFrameOnly() nsCSSFrameConstructor::ConstructTableRowFrame() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableGroupFrameOnly() nsCSSFrameConstructor::ConstructTableGroupFrame() nsCSSFrameConstructor::ConstructTableFrame() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::ContentAppended() StyleSetImpl::ContentAppended() PresShell::ContentAppended() nsDocument::ContentAppended() nsHTMLDocument::ContentAppended() HTMLContentSink::NotifyAppend() SinkContext::FlushTags() HTMLContentSink::CloseBody() CNavDTD::CloseBody() CNavDTD::CloseContainer() CNavDTD::CloseContainersTo() CNavDTD::CloseContainersTo() CNavDTD::DidBuildModel() nsParser::DidBuildModel() nsParser::ResumeParse() nsParser::OnStopRequest() nsDocumentOpenInfo::OnStopRequest() nsHTTPChannel::ResponseCompleted() nsHTTPServerListener::OnStopRequest() nsOnStopRequestEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4062352a) libglib-1.2.so.0 + 0xfbe6 (0x40624be6) libglib-1.2.so.0 + 0x101a1 (0x406251a1) libglib-1.2.so.0 + 0x10341 (0x40625341) libgtk-1.2.so.0 + 0x8c209 (0x4054c209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x4030b1eb)
Keywords: pp
Hardware: PC → All
|
|
||
Comment 26•24 years ago
|
||
Ah -- boy do I feel sheepish. Endico did in fact say Linux, but I say the ALL in the platform field and *automatically* translated this to mean all OS's. (Obviously an erroneous assumption). Thanks for being patient. Waqar: can you please take a look into this crasher for me?
Assignee: rickg → waqar
|
||
Comment 27•24 years ago
|
||
I crashed on NT with 2000032006 build. You can see the stack trace at http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=7196377
|
|
||
Comment 28•24 years ago
|
||
Bruce's comment indicates that this is a memory error. Something is writing past the end of an array. This is happening on all platforms but linux happens to be the only one that reacts by crashing immediately. So it makes sense that this bug would cause crashes on NT, but less frequently. I bet reloading the page over and over or viewing a bunch of wired.com pages in a row would make it crash on nt.
|
|
||
Comment 30•24 years ago
|
||
oops, nearly forgot about updating the OS. pardon to spam...
OS: Linux → All
|
|
||
Comment 31•24 years ago
|
||
seems like this would be pretty easy to track down with purify on any platform, thanks to bruce's good work with the test case. in fact, is the info he provides enough?
Question: has jst's patch made it into the tree? Sounds like it solves the problem (at least, one set of problems) for Dawn and others.
|
|
||
Comment 33•24 years ago
|
||
Did I miss something here?, is there something wrong with the patch in my 2000-03-18 12:27 comment?. Given the nature of this problem stacktraces don't help much here, since the parser writes to a wild pointer mozilla can crash *anywhere*, or as we've seen on some platforms it might not even crash. The purify log that bruce submitted shows where the problem is and my patch fixes the problem, the only question that remains is, does it break the parser?
|
||
Comment 35•24 years ago
|
||
After talking to harish he wants the bug.
Assignee: waqar → harishd
Status: ASSIGNED → NEW
|
|
||
Comment 36•24 years ago
|
||
I'm inclined to agree with jst' assessment. We'll update the DTD accordingly.
|
Reporter | |
Comment 37•24 years ago
|
||
Fortunately for Mozilla users everywhere, Wired decided to implement good web design (maybe because I emailed them about it). They now close all their font tags, and the page loads properly.
|
Assignee | |
Comment 38•24 years ago
|
||
FYI: Fix checked in ( a couple of days back ). Thanx to jst for spotting out the problem. Forgot to mark this bug FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
|
||
Comment 39•24 years ago
|
||
*** Bug 31137 has been marked as a duplicate of this bug. ***
|
|
||
Comment 40•24 years ago
|
||
Verified Fixed on Linux build 2000-04-24-09 (Red Hat 6.2, kernel 2.2.12) and Win32 build 2000-04-24-08 (WinNT4 SP6) - the test cases for bug 31137, bug 31312 and this one all work perfectly.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•