265867 - Crash w/ float, margin, and padding FF10 Trunk [@ nsBlockFrame::SplitPlaceholder]

Status: VERIFIED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Robert Strong (they/them - no direct email)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0

A crash can occur when viewing the soon to be attached simplified testcase.

Reproducible: Always
Steps to Reproduce:
1. Open the testcase
2.
3.

Actual Results:  
Crash

Expected Results:  
No crash

Happens with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041023
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0

TB1493542K

Comment 1

[Robert Strong (they/them - no direct email)]

Attachment: Testcase (causes crash)

Comment 2

[Robert Strong (they/them - no direct email)]

Adding keywords crash and testcase

Comment 3

[Hermann Schwab]

two identical stack traces, Mozilla Trunk:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsBlockFrame%3A%3ASplitPlaceholder+cc822330&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Stack Signature	 nsBlockFrame::SplitPlaceholder cc822330
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3923

Comment 4

[Hermann Schwab]

Firefox 1.7.3: 2004102405 is crashing on the testcase without talkback comming up

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041024
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB1494853K

both installed from zip, deleted compreg.dat to get Talkback going.
Mozilla´s Talkback is working after this, Firefox´ Talkback still doesn´t work.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

Confirming bug.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This worksforme with a current trunk build on Linux...

Comment 7

[Bernd]

this is wfm winxp 2004111204

Comment 8

[Robert Strong (they/them - no direct email)]

Testcase still crashes for me using winxp pro sp2 and 20041112
The latest talkback is TB1912504W but it hasn't been processed on the server as
of this post.

Comment 9

[Robert Strong (they/them - no direct email)]

Adding URL of http://exchangecode.com/crashbugs/265867.html which contains the
original testcase and three additional testcases that I have not reported due to
believing these are probably this same bug. Each testcase is URL encoded in the
page itself. These all crash for me with winxp pro sp2 and Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041112. I also verified that the
original testcase causes a crash with a debug build from today on winxp pro sp2.

Comment 10

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041201
Firefox/1.0+

No crash here with the test case.

Is there more than one bug here? If just the one, is it known to be fixed?

Comment 11

[Robert Strong (they/them - no direct email)]

(In reply to comment #10)
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041201
> Firefox/1.0+
> 
> No crash here with the test case.
> 
> Is there more than one bug here? If just the one, is it known to be fixed?

There is only one bug here and there are additional testcases that are likely
this same bug. It is possible that this doesn't affect Macs.

The original testcase still crashes for me with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041130
Firefox/1.0+ as well as with the Suite
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2286670G

Comment 12

[Mats Palmgren (inactive)]

Testcase number 4 in the URL also crashes on Linux.
Fixing nsBlockFrame::SplitPlaceholder as explained in bug 255748 comment 18
fixes the crash (at least the one I can reproduce).

Comment 13

[Mats Palmgren (inactive)]

Attachment: wip

Comment 14

[Jay Patel [:jay]]

Adding topcrash keyword to get this on the radar since we have a reproducible
testcase.  Stack signature is the same as printing bug 248825, which was
partially fixed to prevent the crash.  I wonder if this is related in anyway? 

Has anyone been able to reproduce this with a recent Trunk build?  I found a
couple of fresh incidents that looked like this:
Incident ID: 2883765
Stack Signature	nsBlockFrame::SplitPlaceholder cf9385c4
Product ID	MozillaTrunk
Build ID	2005010204
Trigger Time	2005-01-02 22:51:42.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	gklayout.dll + (0003eea9)
URL visited	
User Comments	
Since Last Crash	995 sec
Total Uptime	37549 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 4166
Stack Trace 	
nsBlockFrame::SplitPlaceholder 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 4166]
nsBlockFrame::ReflowInlineFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 4076]
nsBlockFrame::DoReflowInlineFrames 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 3809]
nsBlockFrame::ReflowInlineFrames 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 3698]
nsBlockFrame::ReflowLine 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2723]
nsBlockFrame::ReflowDirtyLines 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2234]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 835]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsContainerFrame.cpp,
line 966]
CanvasFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsHTMLFrame.cpp,
line 548]
nsFrame::BoxReflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrame.cpp,
line 5368]
nsFrame::DoLayout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrame.cpp,
line 5108]
nsIFrame::Layout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 803]
nsScrollBoxFrame::DoLayout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp,
line 357]
nsIFrame::Layout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 803]
nsBoxFrame::LayoutChildAt 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 2683]
nsGfxScrollFrameInner::LayoutBox 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 1667]
nsGfxScrollFrameInner::Layout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 1843]
nsHTMLScrollFrame::DoLayout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 1083]
nsIFrame::Layout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 803]
nsBoxFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 853]
nsHTMLScrollFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 1031]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsContainerFrame.cpp,
line 966]
ViewportFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsViewportFrame.cpp,
line 248]
PresShell::InitialReflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 2758]
nsContentSink::StartLayout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsContentSink.cpp,
line 955]
HTMLContentSink::StartLayout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/document/src/nsHTMLContentSink.cpp,
line 3654]
HTMLContentSink::OpenBody 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/document/src/nsHTMLContentSink.cpp,
line 2763]
CNavDTD::OpenBody 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/CNavDTD.cpp,
line 2988]
CNavDTD::OpenContainer 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/CNavDTD.cpp,
line 3214]
CNavDTD::HandleDefaultStartToken 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/CNavDTD.cpp,
line 1315]
CNavDTD::HandleStartToken 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/CNavDTD.cpp,
line 1659]
CNavDTD::HandleToken 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/CNavDTD.cpp,
line 901]
CNavDTD::BuildModel 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/CNavDTD.cpp,
line 464]
nsParser::BuildModel 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsParser.cpp,
line 2028]
nsParser::ResumeParse 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsParser.cpp,
line 1892]
nsParser::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/parser/htmlparser/src/nsParser.cpp,
line 2573]
0x030fdb98
necko.dll + 0x5d0dc (0x6090d0dc)
nsHttpChannel::AddRef 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 2784]
0x8b5610ec

Comment 15

[Robert Strong (they/them - no direct email)]

The original testcase still crashes for me
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2923969W
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050103
Firefox/1.0+

The original testcase hasn't been crashing for some people - possibly due to
differences with the OS - but mats.palmgren has been able to reproduce the crash
with the 4th testcase in the following link which are all possibly the same
crashbug.
http://exchangecode.com/crashbugs/265867.html

Comment 16

[Serge Gautherie (:sgautherie)]

(In reply to comment #4)
> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041024

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20050105] (nightly) (W98SE)

Confirming crash bug, (full installer):
TB2963628Z, trying to load the attached testcase in a new tab.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2963628Z
{{
Stack Signature	 GKLAYOUT.DLL + 0x3eef9 (0x6028eef9) 1d6e03cf
}}

Windows reported:
{{
MOZILLA a causé une défaillance de page dans
 le module GKLAYOUT.DLL à 0167:6028eef9.
Registres :
EAX=00000000 CS=0167 EIP=6028eef9 EFLGS=00010246
EBX=0259cd68 SS=016f ESP=0063d758 EBP=0063d764
ECX=0259cd68 DS=016f ESI=00000000 FS=0e87
EDX=00000003 ES=016f EDI=0171b590 GS=0000
Octets à CS : EIP :
8b 46 20 89 47 20 83 66 20 00 e8 55 07 00 00 85 
État de la pile :
0171b590 019348c0 0063d9f0 0063d798 6028ec3c 01cd9850 00000000 019348c0 0063d9f0
00000001 0063d9f0 0063d7fc 00000000 00000000 00000000 0259cd68 
}}

Comment 17

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041122] (release) (W98SE)

Better crash:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2963944E
{{
Stack Signature	 nsBlockFrame::SplitPlaceholder de04a166
}}

Windows:
{{
MOZILLA a causé une défaillance de page dans
 le module GKLAYOUT.DLL à 0167:6026d5cd.
Registres :
EAX=00000000 CS=0167 EIP=6026d5cd EFLGS=00010246
EBX=0177e1a8 SS=016f ESP=0063dd84 EBP=0063dd90
ECX=0177e1a8 DS=016f ESI=00000000 FS=0e97
EDX=00000013 ES=016f EDI=026690d8 GS=0000
Octets à CS : EIP :
8b 46 20 89 47 20 83 66 20 00 e8 5a 07 00 00 85 
État de la pile :
026690d8 0177e40c 80000000 0063ddc0 6026d301 029c4e30 00000000 0177e40c 0063e014
00000001 029f8200 ffffffff 00000000 00000000 0177e1a8 0063ddf4 
}}

Comment 18

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20050105] (nightly) (W98SE)

TB2964034Z : same as previous (v1.8a6-0105 is not helping here :-<)
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2964034Z
{{
Stack Signature	 GKLAYOUT.DLL + 0x3eef9 (0x6028eef9) 1d6e03cf
}}


[Netscape® Communicator 4.8 : en-20020722] (W98SE)
[Microsoft Internet Explorer, version 5 (5.00.3105.0106) (128b, SP1)] (<-- =
v5.01) (W98SE)

Both display a blank page: no crash.

Comment 19

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041217] (release) (W98SE)

Confirming on v1.7.x branch too.

TB2964191X :
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2964191X
{{
Stack Signature	 nsBlockFrame::SplitPlaceholder 05cd097a
}}

Comment 20

[Asa Dotzler [:asa]]

who can look at this now that we've got a good test case. Bz or dbaron, can one
of you guys have a look and let us know if there's anything that can be done for
1.8a6?

Comment 21

[Boris Zbarsky [:bzbarsky]]

Asa, there's a wallpaper patch in this bug that's the "right" wallpaper,
probably.  Really fixing this is not happening for 1.8a6; see discussion in bug
255748.

So is this a common crash such that we want to wallpaper it?

Comment 22

[Ben Fowler]

(In reply to comment #11)
> > Is there more than one bug here? If just the one, is it known to be fixed?
> 
> There is only one bug here and there are additional testcases that are likely
> this same bug. It is possible that this doesn't affect Macs.

Comment 12 seems to apply to Mac OS X as well as to linux

Comment 23

[Asa Dotzler [:asa]]

actually, this doesn't seem high enough on the topcrash list to be worth a
wallpaper (Jay, please let me know if this is worse than it appears, thanks.)

Comment 24

[Ben Fowler]

(Whistles a few bars from the Mikado and put head on a nearby big black block)

See comment 11, comment 12, comment 21 and bug 255748 .

When I get the crash from testcase 4 (comment 12) in the debugger,
the local variable contFrame is null.

http://lxr.mozilla.org/seamonkey/source/layout/generic/nsBlockFrame.cpp#4160

On the next line, we dereference it.

I suggest this guard or spackle

  if( !contFrame ) {
    NS_WARNING( "nsBlockFrame::SplitPlaceholder contFrame is unexpectedly null" );
    return NS_ERROR_NULL_POINTER;
  }
  nsIFrame *next = contFrame->GetNextSibling();

ahead of the call to GetNextSibling on line 4161 .

Kindly note that this is not the same as the wallpaper as comment 13, that 
seems to be a work in progress to produce an engineered fix to the underlying
problem. That patch probaly covers more cases than mine. My patch is simply 
a guard to prevent the use of a null pointer.

Whilst I see no bar to applying my patch (refusing to use a null pointer
can hardly be more disruptive than trying to de-reference it), note that
there is a proviso in the first paragraph of Bug 255748 comment 18. However
the remainder of that comment would seem to support me, but that is really
for Mats Palmgren to say.

I can now go to testcase 4 without crashing here or anywhere else. 

It follows that:

either GetNextSibling() should be adjusted to never return a null pointer,
or all its callers should check the result against null before using it.
(or indeed in debug mode check that it is a plausible frame)

perhaps nsBlockFrame::ReflowInlineFrame( ) should check the data
that it passes to nsBlockFrame::SplitPlaceholder( )

if this change does cause downstream problems then 
nsBlockFrame::ReflowInlineFrame( ) will need to check the value that
nsBlockFrame::SplitPlaceholder( ) returns.

Comment 25

[Mats Palmgren (inactive)]

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

Comment 26

[Jay Patel [:jay]]

This is actually a common crash for a lot of Firefox 1.0 users and also in the
top 20 for recent MozillaTrunk Talkback data, so if there is a chance that we
can prevent a good number of these crashes with a null check or wallpaper patch,
I say we do it.  

However, if we know how far along we are for the real fix, we can wait to get
that in before the next major release.

Boris:  Any idea when we'll see the changes roc mentions in bug 255748?

Comment 27

[Boris Zbarsky [:bzbarsky]]

I don't really know... ask roc?

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: testcase

This is adapted from 'testcase #4' referred to earlier. It's just this:

<DIV STYLE="display:table-column-group;">
  <DIV>Hello</DIV>
</DIV>

The sign of trouble is a failed assertion in
nsCSSFrameConstructor::ConstructTableForeignFrame line 3622:

  NS_ASSERTION(nsLayoutAtoms::tableCaptionFrame == parentFrame->GetType() ||
	       parentFrame == aState.mPseudoFrames.mCellInner.mFrame,
	       "Weird parent in ConstructTableForeignFrame");

I'm not at all sure how to handle content placed in a table-column-group...
over to bz or bernd

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Note that we should never be splitting placeholders outside of print/print
preview/columns ... so just getting into SplitPlaceholder is a sign that
something has gone drastically wrong elsewhere, and changing how we do
placeholder splitting is not going to be relevant.

Comment 30

[Boris Zbarsky [:bzbarsky]]

> I'm not at all sure how to handle content placed in a table-column-group...

This is actually unspecified in CSS2.1.  I've sent mail to www-style...

In practice, I'd say the reasonable thing to do is to simply not construct
frames for kids of a table-column-group unless their display is table-column
(and to not construct frames for kids of a table-column at all).

Comment 31

[Bernd]

see bug 239294 and https://bugzilla.mozilla.org/show_bug.cgi?id=230138#c7

Comment 32

[Bernd]

Could we split the colgroup case from the rest of this bug. This bug now
references 4 different testcase in the URL and shows stacktraces that do not
have even a single table frame on the stack trace.  I filed bug 280618 for this.

Comment 33

[Robert Strong (they/them - no direct email)]

I just checked the testcases and now only the original testcase and the testcase
that has been split off to bug 280618 still crash and I have updated
http://exchangecode.com/crashbugs/265867.html to reflect this.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050129 Firefox/1.0+
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3420184Y

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The testcase https://bugzilla.mozilla.org/attachment.cgi?id=163225 (which I
believe is the same as the testcase on the exchangecode page) does not crash for
me, not when I open it and not even when I Print Preview it. Linux GTK2. Is this
platform specific now?

Comment 35

[Robert Strong (they/them - no direct email)]

I believe the first testcase (
https://bugzilla.mozilla.org/attachment.cgi?id=163225 ) and is also listed as
"Original reduced testcase" on the exchangecode site has only ever crashed with
Win32 from reading the comments where it has been confirmed (one states Win98 as
well) and I can only confirm with WinXP. It has also been stated not to crash
with Mac OS X and Linux. The other testcases on exchangecode no longer crash for
me as stated on the page except for the one that was split off as bug 239294
which appears to be fixed though I haven't verified it. From this it does appear
to be OS specific to Win32 so I am changing the OS to Windows XP... please
change if this is not incorrect.

Comment 36

[Bernd]

wfm winxp 2005030305

Comment 37

[Robert Strong (they/them - no direct email)]

Attachment: stack trace

stack trace from the crash when viewing the file locally using a debug build
from today

Comment 38

[Robert Strong (they/them - no direct email)]

Attachment: assertions

Assertions before the crash when viewing the file locally using a debug builg
from today. Both the assertions and stacktrace were on winxppro sp2

Comment 39

[Bernd]

I think I fixed the table pseudo issue so removing it from the status. Robert
what file did you use for.
>viewing the file locally 

Comment 40

[Robert Strong (they/them - no direct email)]

I used a debug build of seamonkey from 03-08. I also experience crashes with the
nightly trunk builds of both seamokey and firefox viewing it from bugzilla as
well as locally. I just specified locally since at times I have seen that the
stack trace is different.

Comment 41

[Bernd]

may be my english is not clear, which testcase did you  use?, this bug has a
plenty of them.

Comment 42

[Robert Strong (they/them - no direct email)]

Sorry about that... it was lack of sleep on my part. I was using the first
testcase ( https://bugzilla.mozilla.org/attachment.cgi?id=163225 ). Also, all
testcases except the first one no longer crash as of the beginning of February
which is also noted on the page on exchangecode. I am removing the url from this
bug and it is probably appropriate to obsolete the second attached testcase
since that became bug 239294.

Comment 43

[Robert Strong (they/them - no direct email)]

correction - bug 280618 is the bug for the second testcase.

Comment 44

[Robert Strong (they/them - no direct email)]

I went through my crashes to be reduced this evening and found another that
appears to be this same bug. Since the last time I did that a new bug was found
I updated the url to include only this bug's testcase and the additional
testcase I found this evening. http://exchangecode.com/crashbugs/265867.html

Comment 45

[Martijn Wargers (dead)]

My debug build with the patch from bug 263825 doesn't crash with the "Testcase
(causes crash). My regular trunk build does crash with it.

Comment 46

[Robert Strong (they/them - no direct email)]

Testing with a beast build it appears that the checkin for bug 263825 has fixed
this crash. Thank you roc for fixing this and Martijn for the heads up.

Comment 47

[Stephen Donner [:stephend] Not actively reading bugmail]

Both testcases:

https://bugzilla.mozilla.org/attachment.cgi?id=173036
and
https://bugzilla.mozilla.org/attachment.cgi?id=163225

no longer crash for me with build 2005-03-23-05, Windows XP Seamonkey trunk.

Verified FIXED

Comment 48

[Bob Clary [:bc] (inactive)]

layout/generic/crashtests/265867-1.html
layout/generic/crashtests/265867-2.html
http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3