Closed
Bug 94241
Opened 23 years ago
Closed 23 years ago
These urls cause OnStopDecode assert/crash (in mozilla & mfcembed)
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
People
(Reporter: depman1, Assigned: nivedita)
Details
0.9.3+ 20010807 full build. 1. Launch mozilla.exe or mfcembed. 2. Enter one of these urls in url field: http://www.airliners.net/search/photo.search http://al4a.com/links.html http://cards.webshots.com/69278202264 3. Press Enter. Result: Get this assert: OnStopDecode called multiple times: !(mState & onStopDecode), file /mozilla/modules/libprOn/src/imgRequest.cpp line 512. Press Ignore twice to return control to the app. call stack (into imgRequest): nsDebug::Assertion(const char * 0x01ec6430, const char * 0x01ec6414, const char * 0x01ec63d8, int 512) line 290 + 13 bytes imgRequest::OnStopDecode(imgRequest * const 0x01fc5dc4, imgIRequest * 0x00000000, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 512 + 39 bytes EndGIF(void * 0x0356d6e0, int 0) line 309 gif_write(gif_struct * 0x0356d1c0, const unsigned char * 0x028c1d58, unsigned int 512) line 1531 + 22 bytes nsGIFDecoder2::ProcessData(nsGIFDecoder2 * const 0x0356d6e0, unsigned char * 0x028c1d58, unsigned int 512) line 205 + 20 bytes ReadDataOut(nsIInputStream * 0x01fc2920, void * 0x0356d6e0, const char * 0x028c1d58, unsigned int 4096, unsigned int 512, unsigned int * 0x0012faf0) line 155 + 17 bytes nsPipe::nsPipeInputStream::ReadSegments(nsPipe::nsPipeInputStream * const 0x01fc2920, unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* 0x03491da0 ReadDataOut(nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *), void * 0x0356d6e0, unsigned int 4608, unsigned int * 0x0012fd2c) line 411 + 29 bytes nsGIFDecoder2::WriteFrom(nsGIFDecoder2 * const 0x0356d6e0, nsIInputStream * 0x01fc2920, unsigned int 4608, unsigned int * 0x0012fd2c) line 229 imgRequest::OnDataAvailable(imgRequest * const 0x01fc5dc8, nsIRequest * 0x01fc4550, nsISupports * 0x00000000, nsIInputStream * 0x01fc2920, unsigned int 0, unsigned int 4608) line 739 + 47 bytes ProxyListener::OnDataAvailable(ProxyListener * const 0x01fc46f0, nsIRequest * 0x01fc4550, nsISupports * 0x00000000, nsIInputStream * 0x01fc2920, unsigned int 0, unsigned int 4608) line 402 nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x01fc4554, nsIRequest * 0x01fc2c44, nsISupports * 0x00000000, nsIInputStream * 0x01fc2920, unsigned int 0, unsigned int 4608) line 2179 + 57 bytes nsOnDataAvailableEvent::HandleEvent() line 178 + 70 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02f9ec14) line 64 PL_HandleEvent(PLEvent * 0x02f9ec14) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x010ebae0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x11530114, unsigned int 49430, unsigned int 0, long 17742560) line 1071 + 9 bytes USER32! 77e71820() 010eba
when you load locally the following testcase layout\html\tests\table\bugs\bug10633.html you will also see the assertions., huh, how did your checkin passed the layout regression tests? :-)
Reporter | ||
Comment 3•23 years ago
|
||
per WRMB discussion, making dependent of 90787 topembed.
Keywords: topembed
Comment 4•23 years ago
|
||
Please explain to me why asserts are a topembed bug. Asserts only happen on debug builds, and last I checked, people don't ship debug builds.
Reporter | ||
Comment 5•23 years ago
|
||
Changing qa contact to depstein. OK, these urls are working fine in the 8/17 nightly build. Only a problem in the debug builds. Removing topembed keyword. Sorry about that.
Keywords: topembed
QA Contact: mdunn → depstein
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 6•23 years ago
|
||
Giving to nivedita
Assignee: pavlov → nivedita
Target Milestone: Future → ---
Comment 7•23 years ago
|
||
dup of 78134 *** This bug has been marked as a duplicate of 78134 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•