Follow a link to a news story on this site a couple of days ago, crash and forgot about it. Hit another one today, same thing. So I tried the server address above, same thing again. The page starts to render (incremental reflow ROCKS btw) and partially load several images (banners) when I get the AV. I am not running the Full Circle builds because NNTP is firewalled at my site, sorry. I picked layout as component, but thats just a guess.

Pam, we're crasjing in the image lib. I probably don't have the latest changes, so this may already be fixed. il_icon_notify(_IL_ImageReq * 0x00029a36, int 17, long 10) line 505 + 3 bytes il_container_aborted(il_container_struct * 0x01e25380) line 1111 + 13 bytes il_bad_container(il_container_struct * 0x01e25380) line 1148 + 9 bytes IL_StreamAbort(il_container_struct * 0x01e25380, int -201) line 1626 + 9 bytes NetReaderImpl::StreamAbort(NetReaderImpl * const 0x01e25db8, int -201) line 113 + 16 bytes ImageConsumer::OnDataAvailable(ImageConsumer * const 0x01e25c28, nsIChannel * 0x01edc1e8, nsISupports * 0x00000000, nsIInputStream * 0x0204ef88, unsigned int 0, unsigned int 1255) line 217 nsChannelListener::OnDataAvailable(nsChannelListener * const 0x01e25a00, nsIChannel * 0x01edc1e8, nsISupports * 0x00000000, nsIInputStream * 0x0204ef88, unsigned int 0, unsigned int 1255) line 1597 nsChannelListener::OnDataAvailable(nsChannelListener * const 0x01f15b70, nsIChannel * 0x01edc1e8, nsISupports * 0x00000000, nsIInputStream * 0x0204ef88, unsigned int 0, unsigned int 1255) line 1597 nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 0x02a5e2f0, nsIChannel * 0x028f7e10, nsISupports * 0x01edc1e8, nsIInputStream * 0x0204ef88, unsigned int 0, unsigned int 1255) line 207 + 55 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x02a5e428) line 370 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02048210) line 93 + 12 bytes PL_HandleEvent(PLEvent * 0x02048210) line 537 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00b64e78) line 498 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00060270, unsigned int 49394, unsigned int 0, long 11947640) line 972 + 9 bytes USER32! 77e135f8() USER32! 77e13769() USER32! 77e17b9a() main(int 1, char * * 0x00a92fa8) line 137 + 11 bytes mainCRTStartup() line 338 + 17 bytes

thanks Troy. I check it. -pn

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

This isn't a duplicate though the effect on the imglib is similar. I'm still investigating. Please note that on 2 of the 4 banner ads on the page the contenttype is not sent as 'image/gif' or 'image/jpg'. It is sent as 'text/plain'. An error, but we should be able to handle it without crashing. -pn

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

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

Adding [DOGFOOD] to the summary. There is a error status that is propogating through necko to the imglib. I need some necko help on this one.

The problem on the page is one of the ads. If you use the ad server url: http://VNU.eu-adcenter.net/ with communicator 4.x, you see a benign page. With mozilla, you get a SERVER HANGUP. -pn

Jud: Could this be similar to the etrade problem you just debugged, where their server isn't liking our request?

I'm not sure who's generating the "Server hangup" text (I think it's coming from layout or something. The problem lies in a 302 server redirect for: http://VNU.eu-adcenter.net/image.ng I'm not sure what the problem is though, un-intended propagation of an error code causing layout image lib to barf, then layout???

Putting on the PDT+ radar.

looks like a few people saw this on slashdot in M11

Warren, Judson: I'm back. Sorry about the red herring on the 'server hangup' info. It seemed important at the time. I'm seeing the crash when a reader is gotten from mURL and the image container attached to that reader is garbage/or/freed. It looks like it only happens on an ad that is a redirect. http://VNU.eu-adcenter.net/image.ng/id=-1340208722&site=vnunet&pageposition=top fyi -pn

per rpotts request. I'm marking dup *** This bug has been marked as a duplicate of 20490 ***

Agreed. Marking this as verified dup of 20490.