Closed Bug 243528 Opened 19 years ago Closed 19 years ago

M17 FF09x browser crashes when loading page [@ nsHTMLReflowState::Init]

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 228557

People

(Reporter: sbrewer, Unassigned)

References

(
URL
)

Details

(Keywords: crash, topcrash+)

Crash Data

Attachments

(3 files)

crashlog from loading dubya's site
31.05 KB, text/plain
Details
Minimal testcase for crash (with flashblock installed)
302 bytes, text/html
Details
Another minimal testcase crasher (with flashblock installed)
429 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421

The browser crashes when loading the page.  The title loads, but then the
windows vanish and the message "the application mozilla has quit unexpectedly"
appears.

Reproducible: Always
Steps to Reproduce:
1. open browser
2. type "http://www.georgewbush.com/" in location field
3. hit return

Actual Results:  
browser crashed 

Expected Results:  
loaded dubya's hideous site

I'm using Mozilla 1.7b with the "flashblock" xpi installed.  I will attach the
crashlog which says the exception was:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000018

    
    

    
  
Worksforme, with a current Linux trunk build.  Is this a problem without flashblock?

The stack looks like bug 237760, basically.
Depends on: 237760

    
    

    
  
wfm Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040510

    
    

    
  
I can reproduce this crash on Mac OS X 10.3.3 with flashblock installed, and can
confirm it does not crash without flashblock on the same system.

Reproduced in:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040513

    
    

    
  
So what is flashblock and what does it do?

    
    

    
  
And more to the point, why is this not a flashblock bug?

    
    

    
  
OK, even with flashblock installed I cannot reproduce on Linux.  Could someone
seeing the crash post a talkback ID or at least a MacsBug stack?

    
    

    
  
> Could someone
seeing the crash post a talkback ID or at least a MacsBug stack?

Comment 1? :)

WFM using Mac/1.7b with and without Flashblock installed. Steve and Brion, can
you reproduce this starting with a new Mozilla user profile with or without
Flashblock?

Or, is this just a dup of bug 237760 per Boris in comment 2?
Severity: normal → critical
Keywords: crash
Summary: browser crashes when loading page → browser crashes when loading page [@ nsHTMLReflowState::Init]

    
    

    
  
Brion says he sees it in 

  Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040513

so it wouldn't be a dup of bug 237760, I would think... That patch went in
before that.

Greg, could you test a trunk build?

    
    

    
  
Still WFM using Mac/2004-05-13-08-trunk w/Flashblock.

    
    

    
  
Still crashes for me on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8a) Gecko/20040513

Steps to reproduce:
1. Create new profile
2. Visit http://flashblock.mozdev.org/ and install flashblock
3. Quit and restart Mozilla, in the new profile
4. Visit http://www.georgewbush.com/ (crashes)

Or slightly more complex:
1. Create new profile
2. Visit http://www.georgewbush.com/ (works, with flash)
3. Install flashblock at flashblock.mozdev.org
4. Quit and restart mozilla in the new profile
5. Visit http://www.georgewbush.com/ (works, with flashblock)
6. Clear cache
7. Quit and restart mozilla
8. Visit http://www.georgewbush.com/ (crashes)


    
    

    
  
So Brion, you're running 10.3.3. What Flash plug-in version?

I'm running 10.2.8 and Flash 7.0 r19.

    
    

    
  
(In reply to comment #12)
> So Brion, you're running 10.3.3. What Flash plug-in version?

Flash 7.0r14.

    
    

    
  
I upgraded the Flash plugin to 7.0 r19, can still reproduce the crash on a newly
created profile.

    
    

    
  
Well, Steve's crash report is OS X 10.2.8-style, so I guess it's not a
Jaguar-Panther issue...

    
    

    
  
Making NEW.  I am seeing this crash too with flashblocker installed.  The site
loads fine without the flashblocker extension.

Here's my incident with Mozilla 1.7 rc2:

Incident ID: 52801
Stack Signature	nsHTMLReflowState::Init 28c3c037
Email Address	jay@mozilla.org
Product ID	Mozilla17
Build ID	2004051408
Trigger Time	2004-05-19 15:30:36.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	gklayout.dll + (0001640e)
URL visited	http://www.georgewbush.com/
User Comments	
Since Last Crash	sec
Total Uptime	sec
Trigger Reason	Access violation
Source File Name
d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
Trigger Line No.	327
Stack Trace 	
nsHTMLReflowState::Init
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp,
line 327]
nsHTMLReflowState::nsHTMLReflowState
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp,
line 221]
nsTableCellFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableCellFrame.cpp,
line 871]
nsContainerFrame::ReflowChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableRowFrame::IR_TargetIsChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp,
line 1226]
nsTableRowFrame::IncrementalReflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp,
line 1114]
nsTableRowFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp,
line 1398]
nsContainerFrame::ReflowChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableRowGroupFrame::IR_TargetIsChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1696]
nsTableRowGroupFrame::IncrementalReflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1373]
nsTableRowGroupFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1279]
nsContainerFrame::ReflowChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableFrame::IR_TargetIsChild
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 2983]
nsTableFrame::IncrementalReflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 2689]
nsTableFrame::Reflow
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 1954]
.
.
.

This does look like bug 237760, but that fix was in before rc2 went out, so this
might be a different problem.  This crash is obviously related to the
flashblocker in some way.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: topcrash
OS: MacOS X → All
Hardware: Macintosh → All
Summary: browser crashes when loading page [@ nsHTMLReflowState::Init] → M17rc2 browser crashes when loading page [@ nsHTMLReflowState::Init]

    
    

    
  
Per bz's request over IRC, these are the assertions and warnings that precede
the crash:

###!!! ASSERTION: View is hidden but widget is visible!: '!visible', file
/home/clfenwi/moz/mozilla/view/src/nsViewManager.cpp, line 1609
Break: at file /home/clfenwi/moz/mozilla/view/src/nsViewManager.cpp, line 1609
^G###!!! ASSERTION: View is hidden but widget is visible!: '!visible', file
/home/clfenwi/moz/mozilla/view/src/nsViewManager.cpp, line 1609
Break: at file /home/clfenwi/moz/mozilla/view/src/nsViewManager.cpp, line 1609
^GWARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580
WARNING: malformed hostname, file
/home/clfenwi/moz/mozilla/netwerk/base/src/nsURLParsers.cpp, line 580

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 25273)]
nsIFrame::GetStyleData(nsStyleStructID) const (this=0x0,
aSID=eStyleStruct_Position) at nsIFrame.h:597
	in nsIFrame.h

    
    

    
  
Can you strip it down to the minimal XBL/CSS that crashes?

I just tried installing flashblock here and all that happened is that flash
doesn't render... it looks like flashblock is not properly updating the chrome
registry.

    
    

    
  


  
I wonder how many voters will consider the quality of each candidate's HTML
come November... Alas, they're both using table layouts. ;)

    
    

    
  
So per bz's request, I dug into the flashbock.jar and edited flashblock.xml :

setTimeout ( function ()

	{

		parent.insertBefore(placeholder, current);

		parent.removeChild(current); 

	}, 100);

where 100 replaces 0.

Proceeded tp fire up Mozilla and loaded the website without a crash.




    
    

    
  
*** Bug 234301 has been marked as a duplicate of this bug. ***

    
    

    
  
Hmm... the script and the text input are both necessary?

    
    

    
  
Yes, if you take away either the script or the text input from the testcase, the
crash disappears.

    
    

    
  
*** Bug 245094 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 235014 has been marked as a duplicate of this bug. ***

    
  
Assignee: general → nobody
Component: Browser-General → Layout
QA Contact: general → core.layout

    
    

    
  
*** Bug 248185 has been marked as a duplicate of this bug. ***

    
    

    
  
M17rc2 -> M17 : Still a topcrasher with Mozilla 1.7 final
Summary: M17rc2 browser crashes when loading page [@ nsHTMLReflowState::Init] → M17 browser crashes when loading page [@ nsHTMLReflowState::Init]

    
    

    
  
I put a updated version of flashblock with a couple of bugfixes in it up on
mozdev this morning.  I can't reproduce this crash, so please let me know if the
new version fixes it.

    
    

    
  
Thing is, XBL shouldn't be able to cause crashes.  Could someone try to create a
testcase that has the minimal XBL needed to trigger the crash?

    
    

    
  
Has anyone been able to reproduce this with the latest Flashblock extension? 
Talkback continues to see a good number of these coming in daily.  

If the fix in Flashblock didn't help, hopefully there is something we can do on
our end to prevent this crash.



    
    

    
  
Adding FF09x to summary for tracking since this is also a topcrasher with
Mozilla 0.9.x.  Marking topcrash+ and nominating for blocking-aviary1.0 since
this is a reproducible crash that many people are seeing with a popular extension.
Flags: blocking-aviary1.0?
Keywords: topcrash → topcrash+
Summary: M17 browser crashes when loading page [@ nsHTMLReflowState::Init] → M17 FF09x browser crashes when loading page [@ nsHTMLReflowState::Init]

    
    

    
  


  
The previous minimal testcase did not crash for me, so I made a new testcase by
removing most of the clutter from the url's testcase.
Surprisingly (or not) it is almost identical to the first testcase, but instead
of :<script language="JavaScript">bw=window.innerWidth;</script>
I use: <script src=""></script>
and this crashes for me every time (with flashblock installed).

I can remove the most part of flash.xml until this:
<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="flashblock">
  <implementation>
    <constructor>
    </constructor>
  </implementation>
</binding>
</bindings>
When I remove the <constructor> element, it does not crash anymore.

Also it does only crash when flash.xml is loaded from chrome. Loading it from
any other url, and it does not crash anymore.

    
    

    
  
"Another minimal testcase crasher" with FlashBlock 0.8.4 on Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 crashes here.


    
    

    
  
Crashes with FlashBlock 0.8.4 on Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7)
Gecko/20040617 also.


    
    

    
  
*** Bug 248572 has been marked as a duplicate of this bug. ***

    
    

    
  

*** This bug has been marked as a duplicate of 228557 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE

    
  
Flags: blocking-aviary1.0?
Crash Signature: [@ nsHTMLReflowState::Init]

          You need to log in
          before you can comment on or make changes to this bug.