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)
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
Reporter | ||
Comment 1•14 years ago
|
||
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*) ]
Comment 2•14 years ago
|
||
Do we have any idea of the regression range here?
Reporter | ||
Comment 3•14 years ago
|
||
The regression window is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124
Comment 4•14 years ago
|
||
Sounds likely to be bug 590252.
Blocks: 590252
blocking2.0: --- → ?
Component: Networking: HTTP → ImageLib
QA Contact: networking.http → imagelib
Updated•14 years ago
|
Assignee: nobody → bobbyholley+bmo
blocking2.0: ? → final+
Assignee | ||
Comment 5•14 years ago
|
||
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?
Reporter | ||
Comment 6•14 years ago
|
||
* 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.
Comment 7•14 years ago
|
||
Didn't we recently blacklist IDM? Did the patches here (or something else in the regression range) change any interfaces?
Assignee | ||
Comment 8•14 years ago
|
||
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
Comment 9•14 years ago
|
||
Those don't seem likely to trigger this sort of thing...
Assignee | ||
Comment 10•14 years ago
|
||
oh wait, it looks like there were quite a lot of other idl changes as well, including nsIChannel - investigating.
Assignee | ||
Comment 11•14 years ago
|
||
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?
Comment 12•14 years ago
|
||
(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.
Comment 13•14 years ago
|
||
Sounds like this should be a dup of one of those bugs, then.
Assignee | ||
Comment 14•14 years ago
|
||
(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
Updated•13 years ago
|
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.
Description
•