Closed
Bug 265867
Opened 20 years ago
Closed 19 years ago
Crash w/ float, margin, and padding FF10 Trunk [@ nsBlockFrame::SplitPlaceholder]
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.8beta2
People
(Reporter: robert.strong.bugs, Unassigned)
References
()
Details
(Keywords: crash, testcase, topcrash+)
Crash Data
Attachments
(5 files)
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
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
Adding keywords crash and testcase
Updated•20 years ago
|
Keywords: talkbackid
Comment 3•20 years ago
|
||
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•20 years ago
|
||
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.
Updated•20 years ago
|
Keywords: talkbackid
Summary: Crash w/ float, margin, and padding → Crash w/ float, margin, and padding [@ nsBlockFrame::SplitPlaceholder ]
Updated•20 years ago
|
Assignee: general → nobody
Component: Browser-General → Layout: Block and Inline
QA Contact: general → core.layout.block-and-inline
Comment 6•20 years ago
|
||
This worksforme with a current trunk build on Linux...
Reporter | ||
Comment 8•20 years ago
|
||
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.
Reporter | ||
Comment 9•20 years ago
|
||
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•20 years ago
|
||
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?
Reporter | ||
Comment 11•20 years ago
|
||
(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•20 years ago
|
||
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).
OS: Windows XP → All
Comment 13•20 years ago
|
||
Comment 14•20 years ago
|
||
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
Flags: blocking1.8a6?
Keywords: topcrash+
Summary: Crash w/ float, margin, and padding [@ nsBlockFrame::SplitPlaceholder ] → Crash w/ float, margin, and padding FF10 Trunk [@ nsBlockFrame::SplitPlaceholder ]
Reporter | ||
Comment 15•20 years ago
|
||
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
Updated•20 years ago
|
Flags: blocking1.8a6? → blocking1.8a6+
Comment 16•20 years ago
|
||
(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 }}
Target Milestone: --- → mozilla1.8alpha6
Comment 17•20 years ago
|
||
[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•20 years ago
|
||
[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•20 years ago
|
||
[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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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.)
Flags: blocking1.8a6+ → blocking1.8a6-
Comment 24•20 years ago
|
||
(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•20 years ago
|
||
*** Bug 278868 has been marked as a duplicate of this bug. ***
Comment 26•20 years ago
|
||
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?
Summary: Crash w/ float, margin, and padding FF10 Trunk [@ nsBlockFrame::SplitPlaceholder ] → Crash w/ float, margin, and padding FF10 Trunk [@ nsBlockFrame::SplitPlaceholder]
Comment 27•20 years ago
|
||
I don't really know... ask roc?
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
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•20 years ago
|
||
> 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).
Updated•20 years ago
|
Whiteboard: table-column pseudos
Comment 31•20 years ago
|
||
see bug 239294 and https://bugzilla.mozilla.org/show_bug.cgi?id=230138#c7
Comment 32•20 years ago
|
||
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.
Reporter | ||
Comment 33•20 years ago
|
||
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
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?
Reporter | ||
Comment 35•20 years ago
|
||
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.
OS: All → Windows XP
Updated•20 years ago
|
Flags: blocking1.8b?
Flags: blocking1.8b?
Flags: blocking1.8b2+
Flags: blocking1.8b-
Comment 36•19 years ago
|
||
wfm winxp 2005030305
Reporter | ||
Comment 37•19 years ago
|
||
stack trace from the crash when viewing the file locally using a debug build from today
Reporter | ||
Comment 38•19 years ago
|
||
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•19 years ago
|
||
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
Whiteboard: table-column pseudos
Reporter | ||
Comment 40•19 years ago
|
||
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•19 years ago
|
||
may be my english is not clear, which testcase did you use?, this bug has a plenty of them.
Reporter | ||
Comment 42•19 years ago
|
||
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.
Reporter | ||
Comment 43•19 years ago
|
||
correction - bug 280618 is the bug for the second testcase.
Reporter | ||
Comment 44•19 years ago
|
||
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•19 years ago
|
||
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.
Depends on: 263825
Reporter | ||
Comment 46•19 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
Target Milestone: mozilla1.8alpha6 → mozilla1.8beta2
Updated•15 years ago
|
Attachment #163225 -
Attachment mime type: text/html → text/html; charset=UTF-16
Comment 48•15 years ago
|
||
layout/generic/crashtests/265867-1.html layout/generic/crashtests/265867-2.html http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3
Flags: in-testsuite+
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsBlockFrame::SplitPlaceholder]
You need to log in
before you can comment on or make changes to this bug.
Description
•