Closed Bug 5762 Opened 26 years ago Closed 26 years ago

Apprunner crashes on this particular page reflow (2 broken images)

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
All
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: elig, Assigned: troy)

References

(
URL
)

Details

* TITLE/SUMMARY Apprunner crashes on this particular page reflow (2 broken images) * STEPS TO REPRODUCE 0) Launch Apprunner 1) View http://www.prometheus-music.com/gecko/formtest4.html (included below as an HTML snippet) * RESULT - What happened Immediate crash. To eliminate the crash, remove the second IMG tag for apheader4.gif. - What was expected Reflow w/o crash. * REGRESSION - Occurs On Mac OS, Win32 & Linux Apprunner (4.29.99 PM optimized build) - Doesn't Occur On Communicator 4.6 pre-RTM Mac OS (4.28.99 build) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM. * (mostly simplified) HTML SNIPPET <HTML> <P><A HREF="http://wire.ap.org/GoToAP.cgi" TARGET="_top"><IMG SRC="/APwire/ static/images/general/apheader4.gif" BORDER="0" HEIGHT="68" WIDTH="406"><IMG SRC= "/APwire/static/images/general/apheader4.gif" BORDER="0" HEIGHT="68" WIDTH="406"> </A><BR></P> <P><B><FONT FACE="Georgia, Verdana, Serif" COLOR="#CCCCCC">The WIRE is the news Web site of the AP, its member newspapers and broadcasters. </FONT></B></P> </BODY></HTML> PowerPC unmapped memory exception at 0AED7BA8 Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0BA4BD90 03142500 PPC 0BA4ADE0 main+006E4 03142360 PPC 0B83A3B8 nsAppShellService::Run()+00018 03142320 PPC 0B86F2AC nsAppShell::Run()+00038 031422A0 PPC 0B86FBE0 nsMacMessagePump::DoMessagePump()+0003C 03142250 PPC 0B86FE48 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00144 03142200 PPC 0B26012C Repeater::DoRepeaters(const EventRecord&)+00030 031421C0 PPC 0B852D50 nsToolkit::RepeatAction(const EventRecord&)+00048 03142170 PPC 0B22AF04 nsEventQueueServiceImpl::ProcessEvents()+00020 03142130 PPC 0B228280 nsHashtable::Enumerate(int (*)(nsHashKey*, void*, void*), void*) +00024 031420F0 PPC 0B27C744 PL_HashTableEnumerateEntries+00060 03142080 PPC 0B227BA4 _hashEnumerate(PLHashEntry*, int, void*)+00024 03142040 PPC 0B22AE8C EventDispatchingFunc(nsHashKey*, void*, void*)+00014 03142000 PPC 0B27BB88 PL_ProcessPendingEvents+00078 03141FB0 PPC 0B27BC28 PL_HandleEvent+00028 03141F70 PPC 0AC9961C HandlePLEvent(CantRenderReplacedElementEvent*)+00018 03141F30 PPC 0AC99598 PresShell::HandleCantRenderReplacedElementEvent(nsIFrame*)+00048 03141EF0 PPC 0AC990FC PresShell::ProcessReflowCommands()+000D4 03141E70 PPC 0AD1322C nsHTMLReflowCommand::Dispatch(nsIPresContext&, nsHTMLReflowMetri cs&, const nsSize&, nsIRenderingContext&)+00024
Assignee: troy → kipp
Hardware: Macintosh → All
Target Milestone: M7
This is an interesting one. Below is the smallest HTML example that reproduces the problem. The key is that there are two IMG elements inside of the A element. If there's only one, then we don't crash We're crashing because there's a reflow command target frame that's already been deleted, and we de-reference it when processing reflow commands. Here's the HTML: <HTML> <A HREF="http://wire.ap.org/GoToAP.cgi"> <IMG SRC="/APwire/static/images/general/apheader4.gif" BORDER="0" HEIGHT="68" WIDTH="406"> <IMG SRC="/APwire/static/images/general/apheader4.gif" BORDER="0" HEIGHT="68" WIDTH="406"> </A> </BODY></HTML> Here's the Purify output that shows the FMR, and when the frame was deleted. It seems that the A element's continuing (inline) frame is deleted, but the [now] deleted next-in-flow still has a dangling reflow command targeted at the now dead frame. This isn't inline specific, it looks more like a general problem and one that I knew we would have sooner or later. We need to have the pres shell clean up the reflow command queue (and the NSPR event queue now that we're using it) when frames are deleted Assigning it to you so you can confirm my suspicion (you know the inline code better), and because I won't have time to fix it by tomorrow [E] FMR: Free memory read in nsHTMLReflowCommand::BuildPath(void) {1 occurrence} Reading 4 bytes from 0x04415898 (4 bytes at 0x04415898 illegal) Address 0x04415898 is argument #4 of nsHTMLReflowCommand::BuildPath(void) Address 0x04415898 is at the beginning of a 64 byte block Address 0x04415898 points to a C++ new block in heap 0x03e90000 Thread ID: 0x9f Error location nsHTMLReflowCommand::BuildPath(void) [nsHTMLReflowCommand.cpp:119] nsHTMLReflowCommand::Dispatch(nsIPresContext&,nsHTMLReflowMetrics&,nsSize const&,nsIRenderingContext&) [nsHTMLReflowCommand.cpp:140] PresShell::ProcessReflowCommands(void) [nsPresShell.cpp:1225] PresShell::HandleCantRenderReplacedElementEvent(nsIFrame *) [nsPresShell.cpp:1340] HandlePLEvent [nsPresShell.cpp:1355] PL_HandleEvent [plevent.c:476] PL_ProcessPendingEvents [plevent.c:437] md_EventReceiverProc [plevent.c:799] TranslateMessageEx [user32.dll] DispatchMessageA [USER32.dll] nsNativeViewerApp::Run(void) [nsWinMain.cpp:53] main [nsWinMain.cpp:102] mainCRTStartup [crtexe.c:338] Allocation location new(UINT) [new.cpp:23] nsFrame::new(UINT) [nsFrame.cpp:163] NS_NewInlineFrame(nsIFrame *&) [nsInlineFrame.cpp:274] nsCSSFrameConstructor::CreateContinuingFrame(nsIPresContext *,nsIFrame *,nsIFrame *,nsIFrame * *) [nsCSSFrameConstructor.cpp:5303] StyleSetImpl::CreateContinuingFrame(nsIPresContext *,nsIFrame *,nsIFrame *,nsIFrame * *) [nsStyleSet.cpp:883] nsHTMLContainerFrame::CreateNextInFlow(nsIPresContext&,nsIFrame *,nsIFrame *,nsIFrame *&) [nsHTMLContainerFrame.cpp:108] nsBlockFrame::CreateContinuationFor(nsBlockReflowState&,nsLineBox *,nsIFrame *,int&) [nsBlockFrame.cpp:2961] nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&,nsLineBox *,nsIFrame *,BYTE *) [nsBlockFrame.cpp:2875] nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&,nsLineBox *,int *) [nsBlockFrame.cpp:2695] nsBlockFrame::ReflowLine(nsBlockReflowState&,nsLineBox *,int *) [nsBlockFrame.cpp:1968] nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) [nsBlockFrame.cpp:1775] Free location delete(void *) [dbgdel.cpp:35] nsFrame::delete(void *) [nsFrame.cpp:163] nsInlineFrame::`vector deleting destructor'(UINT) [raptorhtml.dll] nsFrame::DeleteFrame(nsIPresContext&) [nsFrame.cpp:379] nsContainerFrame::DeleteFrame(nsIPresContext&) [nsContainerFrame.cpp:82] nsInlineFrame::DeleteFrame(nsIPresContext&) [nsInlineFrame.cpp:319] nsBlockFrame::DoRemoveFrame(nsIPresContext *,nsIFrame *) [nsBlockFrame.cpp:4116] nsBlockFrame::DeleteChildsNextInFlow(nsIPresContext&,nsIFrame *) [nsBlockFrame.cpp:4332] nsLineLayout::ReflowFrame(nsIFrame *,nsIFrame * *,UINT&) [nsLineLayout.cpp:971] nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&,nsLineBox *,nsIFrame *,BYTE *) [nsBlockFrame.cpp:2818]
Wow. Now that's a fast bug response! (thanks!)
Status: NEW → ASSIGNED
Priority: P3 → P2
(Just FYI, the 4.30.99 now also crash on http://www.prometheus-music.com/gecko/ formtest.html, too.)
Target Milestone: M7 → M6
Assignee: kipp → troy
Severity: critical → major
Status: ASSIGNED → NEW
troy: I added #ifdef's in the nsImageFrame code that read "#if troy_is_back_from_sabatical" that disables the CantRenderReplaced... code path. I was a bit pressed for time, and didn't want to make matters worse since I'm about to go on sabatical...
Assignee: troy → kipp
Assignee: kipp → troy
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
In the July 1 build, the crash nolonger occurs on all platforms.
You need to log in before you can comment on or make changes to this bug.