42724 - Crash in nsFrameImageLoader::NotifyFrames

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Alek Jeziorek]

Crashes at developer.netscape.com on comm. 2000-06-15-08-M17

Comment 1

[Marc Attinasi]

I get the same stack-trace in a crash in the Preference Dialog. Here is the 
stack from developer.netscape.com (NT build):

nsFrameImageLoader::NotifyFrames(int 1) line 538 + 9 bytes
nsFrameImageLoader::Notify(nsIImageRequest * 0x03ae3b40, nsIImage * 0x00000000, 
nsImageNotification nsImageNotification_kDimensions, int 5, int 10, void * 
0x00000000) line 446
ns_observer_proc(void * 0x03ae1a90, long 2, void * 0x0012f788, void * 
0x03ae3b40) line 80
XP_NotifyObservers(OpaqueObserverList * 0x03ae3a70, long 2, void * 0x0012f788) 
line 259 + 28 bytes
il_dimensions_notify(il_container_struct * 0x03ae37f0, int 5, int 10) line 268 + 
18 bytes
ImgDCallbk::ImgDCBHaveHdr(ImgDCallbk * const 0x03ae16d0, int 5, int 10) line 106 
+ 20 bytes
il_size(il_container_struct * 0x03ae37f0) line 777
ImgDCallbk::ImgDCBImageSize(ImgDCallbk * const 0x03ae16d0) line 178 + 12 bytes
il_gif_write(il_container_struct * 0x03ae37f0, const unsigned char * 0x031bc630, 
long 45) line 1349 + 18 bytes
GIFDecoder::ImgDWrite(GIFDecoder * const 0x03afd7f0, const unsigned char * 
0x031bc630, long 45) line 103 + 20 bytes
IL_StreamWrite(il_container_struct * 0x03ae37f0, const unsigned char * 
0x031bc630, long 45) line 1001 + 26 bytes
NetReaderImpl::Write(NetReaderImpl * const 0x03ae5aa0, const unsigned char * 
0x031bc630, long 45) line 110 + 20 bytes
ImageConsumer::OnDataAvailable(ImageConsumer * const 0x03ae5c80, nsIChannel * 
0x03ae5930, nsISupports * 0x00000000, nsIInputStream * 0x03afd6d4, unsigned int 
0, unsigned int 45) line 436 + 23 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03ae5760, 
nsIChannel * 0x03ae5930, nsISupports * 0x00000000, nsIInputStream * 0x03afd6d4, 
unsigned int 0, unsigned int 45) line 210 + 46 bytes
nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x03ae5560, 
nsIChannel * 0x03ae5930, nsISupports * 0x00000000, nsIInputStream * 0x03afd6d4, 
unsigned int 0, unsigned int 45) line 1239 + 46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x03afd6d0, nsIChannel * 0x03ae5930, nsISupports * 0x00000000, nsIInputStream * 
0x03adb0bc, unsigned int 0, unsigned int 45) line 1165
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x03adcd70, 
nsIChannel * 0x03ac25b4, nsISupports * 0x03ae5930, nsIInputStream * 0x03adb0bc, 
unsigned int 12073, unsigned int 45) line 562 + 67 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03ad5e30) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03ad4fd0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03ad4fd0) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x018ef390) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x02f60696, unsigned int 49434, unsigned int 0, 
long 26145680) line 1032 + 9 bytes
USER32! 77e71820()

Comment 2

[Scott MacGregor]

cc'ing Pam in case she has any ideas.

Comment 3

[pnunn]

taking a look at it now.
-p

Comment 4

[pnunn]

Here's a few notes. My local tree from yesterday doesn't crash
on the test url. And since the test url is in the smoke test, we
can be pretty sure this is from changes checked in yesterday.

I'm guessing that some change to the frames code did something
to create/or reveal the bug. The page has frames. and the
frames have an animated images on it. If a frame is reloaded or
trigger a reflow, it may ask for the animated images' image container.
And since image containers for animated images are not cached, the
code maybe just assuming it can get one from the cache.

This is just a guess. I'm pulling another tree for testing.
I can't see the bug with my working tree from yesterday.

-P

Comment 5

[pnunn]

If I had a current tree I would try:
 1> backing out mozilla/layout/html/style/src/nsCSSRendering.cpp
    dbaron checkin, 06-04-00:19:15

 2> or the files mozilla/layout/html/base/src/nsBlockFrame.cpp, etc.
     buster checkin, 06-14-00: 16:15

If anyone has a current tree, could you check these ideas out???
-P

Comment 6

[Marc Attinasi]

Backing out dbaron's change to nsCSSRendering did not help - trying buster's 
next...

Comment 7

[Marc Attinasi]

Backing out buster's change didn't help either. Good guesses though.

Comment 8

[rubydoo123]

when I crash in the comm build -- this is what shows up in the console -- 
probably not any hlep to you, but just in case

Document http://home.netscape.com/index1.html loaded successfully
DV_E_CLIPFORMAT
S_OK
S_OK
->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
Entry at index 0 is http://developer.netscape.com/
WEBSHELL+ = 4
WEBSHELL+ = 5
*** check number of frames in content area

Comment 9

[Asa Dotzler [:asa]]

someone wanna take this bug off of my list.  thanks.

Comment 10

[Chris McAfee]

*** Bug 42735 has been marked as a duplicate of this bug. ***

Comment 11

[Chris McAfee]

resummarizing to ID the top stack frame, since
we seem to be getting dups on this.

Comment 12

[Chris McAfee]

URL works for me on linux,
crashes on today's 061508 mozilla.org win32.zip download bits.
over to pnunn, to get this off asa's list.

Comment 13

[kinmoz]

A fix for this was checked in. This was very similar to bug #42725.

Comment 14

[pnunn]

gee. thanks mcafee.
-p

Comment 15

[Marc Attinasi]

*** Bug 42770 has been marked as a duplicate of this bug. ***

Comment 16

[Doron Rosenberg (IBM)]

this works on 200061608 win98 mozilla build. Verifying.