bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.
Please report any other irregularities here.
Crashes at developer.netscape.com on comm. 2000-06-15-08-M17
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()
cc'ing Pam in case she has any ideas.
taking a look at it now. -p
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
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
Backing out dbaron's change to nsCSSRendering did not help - trying buster's next...
Backing out buster's change didn't help either. Good guesses though.
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
someone wanna take this bug off of my list. thanks.
*** Bug 42735 has been marked as a duplicate of this bug. ***
resummarizing to ID the top stack frame, since we seem to be getting dups on this.
Summary: Crashes at developer.netscape.com → Crash in nsFrameImageLoader::NotifyFrames
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.
A fix for this was checked in. This was very similar to bug #42725.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
gee. thanks mcafee. -p
*** Bug 42770 has been marked as a duplicate of this bug. ***
this works on 200061608 win98 mozilla build. Verifying.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.