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)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 78134

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
this is imagelib. -> pavlov
Assignee: adamlock → pavlov
Blocks: 90787
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? :-)
per WRMB discussion, making dependent of 90787 topembed.
Keywords: topembed
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.
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
No longer blocks: 90787
Target Milestone: --- → Future
Giving to nivedita
Assignee: pavlov → nivedita
Target Milestone: Future → ---
dup of 78134

*** This bug has been marked as a duplicate of 78134 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.