275548 - Crash in [@ nsImageFrame::SourceRectToDest nsIFrame::Invalidate] hovering over table-cell (display:-moz-box) with float:left animated image inside (BuildFloatList removal)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041219 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041219 Firefox/1.0+

See upcoming testcase.
When hovering over the animated image in this testcase, and then close the tab,
I get a crash.
Also when hovering over the image in the testcase, the image somehow gets
duplicated.

Talkback ID's:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2674118G
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2674018K
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2673879Z


Reproducible: Always

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 2

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

nsImageFrame::SourceRectToDest 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsImageFrame.cpp,
line 429]
nsImageFrame::FrameChanged 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsImageFrame.cpp,
line 714]
nsImageListener::FrameChanged 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsImageFrame.cpp,
line 2139]
nsImageLoadingContent::FrameChanged 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsImageLoadingContent.cpp,
line 161]
imgRequestProxy::FrameChanged 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/src/imgRequestProxy.cpp,
line 366]
imgRequest::FrameChanged 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/src/imgRequest.cpp,
line 378]
imgContainerGIF::Notify 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/decoders/gif/imgContainerGIF.cpp,
line 456]
nsTimerImpl::Fire 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 396]
nsTimerManager::FireNextIdleTimer 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 617]
nsAppShell::Run 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 142]
nsAppStartup::Run 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/components/startup/src/nsAppStartup.cpp,
line 216]
main1 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1330]
main 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1801]
WinMain 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1827]
WinMainCRTStartup()
kernel32.dll + 0x16d4f (0x7c816d4f)

Comment 3

[Bernd]

animated imgaes are bad, https://bugzilla.mozilla.org/show_bug.cgi?id=265181#c13

Comment 4

[Bernd]

display:-moz-box seems to be xul box, the wonder is that one really needs an
animated image to crash. Toggling between display:table-cell and a xul box thats
even more evil than hixies testcases. Martijn you should consider fixing rather
than filing more and more evil bugs :-) .

Comment 5

[Martijn Wargers (dead)]

Sorry Bernd, I'm afraid I don't have the necessary brains. Instead I file bugs
;-) . I am only able to fix very simple bugs, sometimes.

I've made a bookmarklet that automatically changes one single style property of
every element in a page. With that I am able to crash Mozilla sometimes.
My plan is to file every crash (if it is not a dupe) with a simple testcase.
That is useful, isn't it?

Comment 6

[Boris Zbarsky [:bzbarsky]]

So.  The immediate cause of the crash is the usual story -- the image frame
involved is 0xdadadada, which means someone didn't Destroy() it before tearing
down the frame PLArena, and we're now sending image animation notifications into
unallocated memory.

The problem then becomes figuring out who'd losing frames... :(

Oh, and Martijn?  What you mention in comment 5 sounds like an excellent idea!

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, the basic issue is that XUL has absolutely no provisions for dealing with
table pseudo-stuff...  So we're ending up with the box a direct child of the
table row, if nothing else.  It goes downhill from there.... :(

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK, fixing things to have a block (per patch to bug 269566) doesn't help much,
since BuildFloatList screws us over then...

Comment 9

[Bernd]

Attachment: revised testcase (does not crash)

The crash is due to the fact that we loose something from our frametree

Comment 10

[Martijn Wargers (dead)]

Well, at least this doesn't crash anymore in a 20050322 trunk build.

Comment 11

[Bernd]

Martijn, so could we close this as WFM?

Comment 12

[Martijn Wargers (dead)]

Yes, I think so.