Closed Bug 286813 Opened 20 years ago Closed 20 years ago

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

Categories

(Core :: Web Painting, defect, P1)

Product:
Core
Component:
Web Painting
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: taviso, Assigned: bzbarsky)

Details

(Keywords: crash, regression, testcase)

Attachments

(3 files)

testcase
790 bytes, text/html
Details
reduced testcase
204 bytes, text/html
Details
Proposed fix
23.66 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
testcase attached crashes nightly build on linux.
Attached file testcase —
Keywords: crash, regression, 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 fix — — Splinter 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: 20 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: