Closed Bug 286813 Opened 19 years ago Closed 19 years ago

[FIX]crash: linux nightly build crash in nsCSSFrameConstructor::CantRenderReplacedElement

Categories

(Core :: Web Painting, defect, P1)

x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: taviso, Assigned: bzbarsky)

Details

(Keywords: crash, regression, testcase)

Attachments

(3 files)

testcase attached crashes nightly build on linux.
Attached file testcase
TB4445115G
Regression window:

2005-01-19-07-trunk OK
2005-01-20-07-trunk CRASH
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4445115G
nsFrameManager::HandlePLEvent() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/layout/base/nsFrameManager.cpp,
line 182]
PL_HandleEvent() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c,
line 699]
PL_ProcessPendingEvents() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c,
line 633]
nsEventQueueImpl::ProcessPendingEvents() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/nsEventQueue.cpp,
line 417]
event_processor_callback() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 67]


http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4450716Y
nsStyleContext::GetStyleData 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/style/nsStyleContext.cpp,
line 247]
nsFrameManager::HandlePLEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsFrameManager.cpp,
line 873]
0x778b0c24
OS: Linux → All
Attached file reduced testcase
reduced the original testcase:

crash depends on length of the string in <embed>
without F Firefox doesn´t crash, but Mozilla crashes.
Without 9F Mozilla doesn´t crash.
String can be replaced by a string of 29 A´s to let Mozilla crash.
Doubling the width of the iframe didn´t cure the crash.
 
<HTML><HEAD><TITLE>286813</TITLE></HEAD><BODY>
	<OBJECT>
		<EMBED>12345678901234567890123456789123456789F<EMBED>
		<OBJECT>
			<IFRAME WIDTH="100"> frame </IFRAME>
		</OBJECT>
	</OBJECT>
</BODY></HTML>
Talkback from reduced Testcase:

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4455192X

nsCSSFrameConstructor::CantRenderReplacedElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 10652]
nsFrameManager::HandlePLEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsFrameManager.cpp,
line 873]
0x778b0c24
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050317

replace the <embed>-string in the reduced testcase from comment 5 with:
		<EMBED>MMMMMMMMMMMMMMMMMMMMMM<br><EMBED>
and Mozilla doesn´t crash.
Then remove the <br> and mozilla crashes. 
Then remove a M, and Mozilla doesn´t crash.

Maybe it depends on screen resolution or fontsize, if it doesn´t crash for you,
add some M´s, if it crashes when it shouldn´t, remove some.
The summary and component don't make sense  based on the testcase, stack, and
comments - changing. Reassigning to bz since that looks more likely of the two
fixes to have caused this.
Assignee: xml → bzbarsky
Component: XML → Layout: View Rendering
Summary: crash: linux nightly build crash in XmlInitUnknownEncodingNS() → crash: linux nightly build crash in nsCSSFrameConstructor::CantRenderReplacedElement
Heikki: I think there's a NULL pointer dereference that's confusing the stack 
trace, this is what I get:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087953872 (LWP 8200)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x081ea5c4 in XmlInitUnknownEncodingNS ()
#2  0x081fe26d in XmlInitUnknownEncodingNS ()
#3  0x40264ee3 in PL_HandleEvent ()
   from /home/taviso/stuff/firefox/firefox/libxpcom_core.so
#4  0x40264e36 in PL_ProcessPendingEvents ()
   from /home/taviso/stuff/firefox/firefox/libxpcom_core.so
#5  0x40266433 in nsEventQueueImpl::CheckForDeactivation ()
   from /home/taviso/stuff/firefox/firefox/libxpcom_core.so
#6  0x081d6c28 in XmlInitUnknownEncodingNS ()
#7  0x407d3991 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
#8  0x407a6fad in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0x407a8079 in IA__g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0x407a839a in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#11 0x407a8a00 in IA__g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#12 0x4042ca53 in IA__gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x081d6ecf in XmlInitUnknownEncodingNS ()
#14 0x085f2665 in nsXPTCVariant::Init ()
#15 0x086e7631 in nsBaseHashtableET<nsStringHashKey, nsCOMPtr<nsIVariant> >::
nsBaseHashtableET ()
...
Attached patch Proposed fixSplinter Review
The problem here is that we were triggering viewmanager code in the middle of
CantRenderReplacedElement and this tried to do a reflow while in the middle of
frame construction, which caused some frames to be destroyed while they were
being worked with.

The substantive part of this patch is the change to increment and decrement
mChangeNestCount around the call to the frame constructor's
CantRenderReplacedElement.  The rest was me moving all the event code from
frame manager to presshell (where it seems to belong better), because I didn't
want to add methods to nsIPresShell that would mess with mChangeNestCount.  I
suppose I can add those instead if you prefer....
Attachment #178625 - Flags: superreview?(dbaron)
Attachment #178625 - Flags: review?(dbaron)
Priority: -- → P1
Summary: crash: linux nightly build crash in nsCSSFrameConstructor::CantRenderReplacedElement → [FIX]crash: linux nightly build crash in nsCSSFrameConstructor::CantRenderReplacedElement
Target Milestone: --- → mozilla1.8beta2
Comment on attachment 178625 [details] [diff] [review]
Proposed fix

r+sr=dbaron.  But are there things that could get lost if mChangeNestCount is
nonzero?
Attachment #178625 - Flags: superreview?(dbaron)
Attachment #178625 - Flags: superreview+
Attachment #178625 - Flags: review?(dbaron)
Attachment #178625 - Flags: review+
Attempts to flush reflow or painting will get ignored while the change nest
count is nonzero.  Other than that, nothing else will get lost.
Fixed
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
layout/base/crashtests/286813-1.html
http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3
Flags: in-testsuite+
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: