Closed Bug 789178 Opened 7 years ago Closed 4 years ago

crash in mozilla::net::nsHttpChannel::OnDataAvailable

Categories

(Core :: Networking, defect, critical)

18 Branch
x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox18 - ---

People

(Reporter: alex_mayorga, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-a8cfe9e6-6859-4564-ad59-39bdd2120906 .
=============================================================
It's currently #4 top crasher in today's build.
It first appeared in 18.0a1/20120906. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6705e131aeaa&tochange=0c4fa25f637b
It's likely a regression from bug 784912.

Signature 	mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int) More Reports Search
UUID	a8cfe9e6-6859-4564-ad59-39bdd2120906
Date Processed	2012-09-06 16:11:17
Uptime	38
Last Crash	47 seconds before submission
Install Age	1.3 hours since version was first installed.
Install Time	2012-09-06 14:49:43
Product	Firefox
Version	18.0a1
Build ID	20120906030518
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 28 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x50
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0xa011, AdapterSubsysID: 02213025, AdapterDriverVersion: 8.14.10.2230
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
EMCheckCompatibility	False
Adapter Vendor ID	0x8086
Adapter Device ID	0xa011
Total Virtual Memory	2147352576
Available Virtual Memory	1641349120
System Memory Use Percentage	50
Available Page File	2918350848
Available Physical Memory	1066049536

Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::net::nsHttpChannel::OnDataAvailable 	netwerk/protocol/http/nsHttpChannel.cpp:5075
1 	xul.dll 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:483
2 	xul.dll 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:371
3 	xul.dll 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:82
4 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:624
5 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
6 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
7 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
8 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
9 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
10 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:273
11 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3835
12 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3912
13 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3988
14 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:100
15 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
16 	kernel32.dll 	BaseThreadInitThunk 	
17 	ntdll.dll 	__RtlUserThreadStart 	
18 	ntdll.dll 	_RtlUserThreadStart

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Anet%3A%3AnsHttpChannel%3A%3AOnDataAvailable%28nsIRequest*%2C+nsISupports*%2C+nsIInputStream*%2C+unsigned+__int64%2C+unsigned+int%29
https://crash-stats.mozilla.com/report/list?signature=nsHTTPCompressConv%3A%3Ado_OnDataAvailable%28nsIRequest*%2C+nsISupports*%2C+unsigned+__int64%2C+char+const*%2C+unsigned+int%29
https://crash-stats.mozilla.com/report/list?signature=%400x0+|+nsHTTPCompressConv%3A%3AOnDataAvailable%28nsIRequest*%2C+nsISupports*%2C+nsIInputStream*%2C+unsigned+__int64%2C+unsigned+int%29
https://crash-stats.mozilla.com/report/list?signature=nsHTTPCompressConv%3A%3AOnDataAvailable%28nsIRequest*%2C+nsISupports*%2C+nsIInputStream*%2C+unsigned+__int64%2C+unsigned+int%29
Blocks: 784912
Crash Signature: [@ mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int)] → [@ mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int)] [@ nsHTTPCompressConv::do_OnDataAvailable(nsIRequest*, nsISupports*, unsigned __int64, char const* unsigned int)] [@ @0x0 | nsHT…
Component: Untriaged → Networking
Keywords: regression, topcrash
OS: Windows NT → Windows 7
Product: Firefox → Core
Version: Trunk → 18 Branch
Duplicate of this bug: 789655
I think that this depends on binary addon since this fix changes idl and uuid.

EXCEPTION_ACCESS_VIOLATION_WRITE (46)

100% (46/46) vs.   4% (92/2228) idmcchandler2.dll
100% (46/46) vs.   4% (92/2228) idmmzcc.dll
96% (44/46) vs.  49% (1102/2228) AudioSes.dll

So what is idmcchanlder2.dll and idmmzcc.dll?
(In reply to Makoto Kato from comment #3)
> So what is idmcchanlder2.dll and idmmzcc.dll?
They are two DLLs from Internet Download Manager:
    100% (46/46) vs.   4% (92/2228) idmcchandler2.dll
         17% (8/46) vs.   1% (14/2228) 6.12.10.1
         20% (9/46) vs.   1% (29/2228) 6.12.11.1
         57% (26/46) vs.   2% (43/2228) 6.12.15.1
          7% (3/46) vs.   0% (6/2228) 6.12.3.1
    100% (46/46) vs.   4% (92/2228) idmmzcc.dll (6.12.5.1)
Summary: crash in mozilla::net::nsHttpChannel::OnDataAvailable → crash in mozilla::net::nsHttpChannel::OnDataAvailable with Internet Download Manager 6.12
From crash reports in comment 1 ,looks like a sudden spike in crashes and then calms down.If it comes us again, please renominate .
(In reply to bhavana bajaj [:bajaj] from comment #5)
> From crash reports in comment 1 ,looks like a sudden spike in crashes and
> then calms down.
If it has calmed down, it's probably because Nightly users made the correlation with IDM and has stopped using either IDM or Nightly. I guess the fix is on IDM developer hands.
Adding a couple of IDM contacts.
All crashes here are for Firefox 18.* which are nightly builds and we don't support them. We set max version to 17.* in our install.rdf. It's possible that some "smart" customer re-builds our extension with a new install.rdf and without our digital signature, claims compatibility with nightly builds, and publishes the link somewhere in forums or on non-official IDM sites. If you have e-mails of customers who suffered from these crashes, you may ask them where they got such version of IDM extension for Firefox 18.
We took a look at Firefox 18 SDK and noticed that nsIStreamListener interface had been changed. We suppose that the problem was because of this change. When Firefox 18 enters Aurora stage, as always we will add the support for Firefox 18 in our official version of extension where new interface changes will be taken into account. But to make Firefox more reliable and protect it from "smart" customers who re-build our extension themselves, we would suggest making an additional verification in nsITraceableChannel::SetNewListener implementation like the following

NS_IMETHODIMP nsITraceableChannel::SetNewListener(nsIStreamListener *aListener, nsIStreamListener **_retval)

{

nsresult rv;

nsCOMPtr<nsIStreamListener> test = do_QueryInterface(aListener, &rv);

if (NS_FAILED(rv) || (! test))

return errcode;

...............................................

}
Adding Benjamin to weigh in on comment #9.
We can't really defensively program against all these sorts of errors, so I don't think we should make the change in comment 9. I guess people are using the extension compatibility assistant to test the new version?
We do not know what people use to make unofficial versions of our extension, the extension compatibility assistant or something else. We have binary components in the extension and we have no idea how people managed to load the extension in FF 18. Maybe all crashes had the same IP address? Can you check it? Are the crashes still happening?

Maybe you changed nsIStreamListener but did not change its ID at the same time. You might have changed the interface ID much later than the interface, and crashes stopped after that? I just don’t know how to see Mozilla crash reports, whether the crashes continue or already stopped.
(In reply to Charles Jones from comment #12)
> Maybe all crashes had the same IP address?
For privacy purposes, the IP address is not saved. Nevertheless, in a same build the Install Time is specific to each user and across builds the processor family and the graphics configuration can help to distinguish users.

> Can you check it? Are the crashes still happening?
They are still happening. You can check with the four links at the end of comment 1.
IMO, the user did not rebuild their extension but change the setting in about:config extensions.checkCompatibility.nightly, this work for me to enable the IDM extension in nightly (FF18) without "rebuild" the extension.

As nightly is for nightly tester to test and help to find out the problem ASAP before FF18 release, I think most of the nightly tester did it to test the extension compatibility.
It's #26 top browser crasher in the first hours of 18.0.
It's no longer correlated to IDM.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsHTTPCompressConv%3A%3AOnDataAvailable%28nsIRequest*%2C+nsISupports*%2C+nsIInputStream*%2C+unsigned+__int64%2C+unsigned+int%29
Summary: crash in mozilla::net::nsHttpChannel::OnDataAvailable with Internet Download Manager 6.12 → crash in mozilla::net::nsHttpChannel::OnDataAvailable
It's now #13 top browser crasher in 18.0 and a low volume crash in 19.0b1 and above.
Keywords: topcrash
(In reply to Scoobidiver from comment #16)
> It's #26 top browser crasher in the first hours of 18.0.
> It's no longer correlated to IDM.
> 
> More reports at:
> https://crash-stats.mozilla.com/report/
> list?signature=nsHTTPCompressConv%3A%3AOnDataAvailable%28nsIRequest*%2C+nsISu
> pports*%2C+nsIInputStream*%2C+unsigned+__int64%2C+unsigned+int%29

These are nsHTTPCompressConv::OnDataAvailable and *not nsHttpChannel* ::OnDataAvailable.
(In reply to Honza Bambas (:mayhemer) from comment #18)
> These are nsHTTPCompressConv::OnDataAvailable and *not nsHttpChannel*
> ::OnDataAvailable.
nsHTTPCompressConv::OnDataAvailable is the crash signature with the highest volume. nsHttpChannel* ::OnDataAvailable are low volume crashes.
Is there any status on this? I've seen a few SUMO Reports. If necessary I can try to do 1:1 outreach
(In reply to Tyler Downer [:Tyler] from comment #20)
> Is there any status on this?
It seems fixed in 19.0b1 and above. See comment 17.
I walked all the crash signatures with containing nsHTTPCompressConv::OnDataAvailable signature (there are plenty of them).  The least frequent are interesting.

There are many cases where it seems like a regular OOM because of large heap fragmentation (not sure how jemalloc handles this):

Realloc failure on 90+ system memory usage:
https://crash-stats.mozilla.com/report/index/ddd1071b-a3ff-4746-8b9e-884cd2130112
https://crash-stats.mozilla.com/report/index/5eaa9338-45c3-48f4-94e3-d1f232130111

Alloc streamLen * 3 on 90+ system memory usage:
https://crash-stats.mozilla.com/report/index/7f6461de-c281-45d8-b956-d5dad2130111
https://crash-stats.mozilla.com/report/index/0d43aa6b-6eb8-474a-916b-c44bb2130101
https://crash-stats.mozilla.com/report/index/667be26f-92e7-4e27-8d9e-df30a2121229
https://crash-stats.mozilla.com/report/index/12183b87-32d6-440e-9d13-f160a2130112

It may happen that aCount may be quit large and is just limited as UINT32_MAX.  We should limit it to some reasonable number.
It's now a low volume crash.
Keywords: topcrash
Crash Signature: , unsigned int)] → , unsigned int)] [@ mozilla::net::nsHttpChannel::OnDataAvailable] [@ nsHTTPCompressConv::do_OnDataAvailable] [@ @0x0 | nsHTTPCompressConv::OnDataAvailable] [@ nsHTTPCompressConv::OnDataAvailable]
(In reply to Scoobidiver (away) from comment #23)
> It's now a low volume crash.

even more so now, at about 2-3 crashes per week for less than half the signatures cited
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
in what version(s) of Firefox do you still see these crashes?
You need to log in before you can comment on or make changes to this bug.