The new layout of wired.com crashes the browser consistently

VERIFIED FIXED in M15

Status

()

P3
blocker
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: sytobinh, Assigned: harishd)

Tracking

({crash, top100})

Trunk
crash, top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-], URL)

Attachments

(4 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
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.

Comment 2

19 years ago
buster, this is probably a dup of bug 31137.
Keywords: crash, top100

Updated

19 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

19 years ago
*** Bug 32308 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Assignee: cbegle → karnaze
Component: Browser-General → HTMLTables
Keywords: css1
OS: Linux → All
QA Contact: asadotzler → chrisd

Comment 4

19 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

19 years ago
Component: HTMLTables → Style System

Comment 5

19 years ago
changing component to style system
Assignee: karnaze → pierre

Comment 6

19 years ago
Created attachment 6670 [details]
full stack trace

Comment 7

19 years ago
My original crash was from my own build from this afternoon. (on linux)
This page crashes m14 as well.
(Reporter)

Comment 8

19 years ago
Created attachment 6671 [details]
HTML File crashed mozilla
(Reporter)

Comment 9

19 years ago
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

19 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
Assignee: pierre → rickg
Component: Style System → Parser
Keywords: css1 → beta1
OS: All → Linux
QA Contact: chrisd → janc

Comment 11

19 years ago
Created attachment 6677 [details]
test case with 17 <p><font>

Comment 12

19 years ago
Created attachment 6678 [details]
stack trace of m14 after viewing the second test case

Comment 13

19 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

19 years ago
That same test case also demonstrates some parser leaking action quite well.
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

19 years ago
I just build mozilla from the nscp_beta1_BRANCH and verified it has
this problem too.

Comment 17

19 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

19 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.
Has this been checked into the Mozilla tip yet?  Does it still need to be
reviewed?

Comment 20

19 years ago
*** Bug 31312 has been marked as a duplicate of this bug. ***

Comment 21

19 years ago
QA: when this bug is fixed, please verify against the test case in bug 31312 as 
well

Comment 22

19 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 23

19 years ago
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]

Comment 24

19 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) 
                                                 

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

19 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

19 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

19 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.
removing pp keyword (after chatting w/dawn).
Keywords: pp
oops, nearly forgot about updating the OS. pardon to spam...
OS: Linux → All

Comment 31

19 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.
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 34

19 years ago
Accepting!
Status: NEW → ASSIGNED
Target Milestone: --- → M15

Comment 35

19 years ago
After talking to harish he wants the bug.
Assignee: waqar → harishd
Status: ASSIGNED → NEW

Comment 36

19 years ago
I'm inclined to agree with jst' assessment. We'll update the DTD accordingly.
(Reporter)

Comment 37

19 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

19 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
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 39

19 years ago
*** Bug 31137 has been marked as a duplicate of this bug. ***

Comment 40

19 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.