Closed Bug 591746 Opened 14 years ago Closed 14 years ago

Crash in [@ nsHttpChannel::AsyncOpen(nsIStreamListener*, nsISupports*) ] or [@ nsLoadGroup::AddRequest(nsIRequest*, nsISupports*) ]

Categories

(Core :: Graphics: ImageLib, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 591880
Tracking Status
blocking2.0 --- final+

People

(Reporter: scoobidiver, Assigned: bholley)

References

Details

(Keywords: crash)

Crash Data

Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100828
Firefox/4.0b5pre

This is a new crash signature which has been introduced by this build and it is
still the #7 crasher for this build.
It appears to be mainly a start-up crash, probably because there is an image to load in the home page.

http://crash-stats.mozilla.com/report/index/4d71d07c-5bb1-497d-a0d6-1b8862100829
Signature	nsHttpChannel::AsyncOpen(nsIStreamListener*, nsISupports*)
UUID	4d71d07c-5bb1-497d-a0d6-1b8862100829
Time 	2010-08-29 01:40:39.749531
Uptime	13338
Last Crash	13341 seconds (3.7 hours) before submission
Install Age	13700 seconds (3.8 hours) since version was first installed.
Product	Firefox
Version	4.0b5pre
Build ID	20100828040640
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0xffffffff931660c4

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0x931660c4 	
1 	xul.dll 	nsHttpChannel::AsyncOpen 	netwerk/protocol/http/nsHttpChannel.cpp:3588
2 	xul.dll 	imgLoader::LoadImage 	modules/libpr0n/src/imgLoader.cpp:1660
3 	xul.dll 	nsLoadGroup::AggregatedQueryInterface 	netwerk/base/src/nsLoadGroup.cpp:210
An other crash signature can be associated to this bug because they are very similar.
It ransk the #10 crasher for this build.

http://crash-stats.mozilla.com/report/index/02992b92-7d8d-4993-919e-8baab2100829
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsLoadGroup::AddRequest 	netwerk/base/src/nsLoadGroup.cpp:559
1 	xul.dll 	nsHttpChannel::AsyncOpen 	netwerk/protocol/http/nsHttpChannel.cpp:3588
2 	xul.dll 	imgLoader::LoadImage 	modules/libpr0n/src/imgLoader.cpp:1660
3 	xul.dll 	nsLoadGroup::AggregatedQueryInterface 	netwerk/base/src/nsLoadGroup.cpp:210
Summary: Crash in [@ nsHttpChannel::AsyncOpen(nsIStreamListener*, nsISupports*) ] → Crash in [@ nsHttpChannel::AsyncOpen(nsIStreamListener*, nsISupports*) ] or [@ nsLoadGroup::AddRequest(nsIRequest*, nsISupports*) ]
Do we have any idea of the regression range here?
Sounds likely to be bug 590252.
Blocks: 590252
blocking2.0: --- → ?
Component: Networking: HTTP → ImageLib
QA Contact: networking.http → imagelib
Assignee: nobody → bobbyholley+bmo
blocking2.0: ? → final+
Looks like both crash reports (different sites, same callstack) have the "internet download manager" extension installed:
https://addons.mozilla.org/en-US/firefox/addon/6973/

Also, I'm pretty confused by the call-stack on the second crash. It's getting a null pointer here:
http://hg.mozilla.org/mozilla-central/annotate/6e3f6d18c124/netwerk/base/src/nsLoadGroup.cpp#l559

Which presumably is the result of de-referencing 'request'. However, 'request' is the 'this' parameter in the caller:
http://hg.mozilla.org/mozilla-central/annotate/6e3f6d18c124/netwerk/protocol/http/nsHttpChannel.cpp#l3588

The caller accesses several member variables before making that call, so it would appear that it should crash earlier.

I guess what's probably happening is that the implementation of GetLoadFlags is dereferencing something else, and is being inlined by PGO.

bz - How should we proceed, given the suspicious extension?
* nsHttpChannel::AsyncOpen(nsIStreamListener*, nsISupports*) crash signature :
It happened only with the following builds : 20100828040640, 20100829040614, 20100830040705

* nsLoadGroup::AddRequest(nsIRequest*, nsISupports*) crash signature :
It happened only with the following builds : 20100828040640, 20100829040614, 20100830040705, 20100831043946

All of them seem to have IDM 5.16.1. Now the IDM version is 5.19.
I think that people who had this crashes updated IDM.
Didn't we recently blacklist IDM?

Did the patches here (or something else in the regression range) change any interfaces?
grepping for patches with superreview to narrow the search, I get changes in the following interfaces:

storage/public/mozIStorageConnection.idl
xpcom/io/nsIScriptableInputStream.idl
content/base/public/nsIImageLoadingContent.idl
Those don't seem likely to trigger this sort of thing...
oh wait, it looks like there were quite a lot of other idl changes as well, including nsIChannel - investigating.
Ahah! I found the changeset:

http://hg.mozilla.org/mozilla-central/rev/f9a4a332f637

I wasn't seeing it using hgweb because it was part of an e10s merge and the hgweb interface hides the baggage of merge commits.

So anyway, it seems to me like that would do it, and that this isn't, in fact a regression from bug 590252.

bz - any objection to resolving invalid or WFM?
(In reply to comment #7)
> Didn't we recently blacklist IDM?
We backed out the patches that changed nsIChannel, and that made the crashes go away.  As a result, we never blocklisted it.
Sounds like this should be a dup of one of those bugs, then.
(In reply to comment #13)
> Sounds like this should be a dup of one of those bugs, then.

Sounds good to me.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ nsHttpChannel::AsyncOpen(nsIStreamListener*, nsISupports*) ] [@ nsLoadGroup::AddRequest(nsIRequest*, nsISupports*) ]
You need to log in before you can comment on or make changes to this bug.