803267 - crash in nsSocketTransportService::DetachSocket

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Scoobidiver (away)]

It spiked from 19.0a1/20121018. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5
It might be a regression from bug 766817 (uplifted to Aurora and Beta).

Signature 	nsSocketTransportService::DetachSocket(nsSocketTransportService::SocketContext*, nsSocketTransportService::SocketContext*) More Reports Search
UUID	f923e4af-f426-4f88-9aeb-338dd2121018
Date Processed	2012-10-18 18:15:31
Uptime	729
Last Crash	2.1 days before submission
Install Age	50.8 minutes since version was first installed.
Install Time	2012-10-18 17:24:35
Product	Firefox
Version	19.0a1
Build ID	20121018030618
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 2 stepping 3
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0xc5e3d00
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0ca3, AdapterSubsysID: 072e10de, AdapterDriverVersion: 8.17.13.142
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x0ca3
Total Virtual Memory	2147352576
Available Virtual Memory	1554419712
System Memory Use Percentage	41
Available Page File	4214034432
Available Physical Memory	1731235840

Frame 	Module 	Signature 	Source
0 		@0xc5e3d00 	
1 	xul.dll 	nsSocketTransportService::DetachSocket 	netwerk/base/src/nsSocketTransportService2.cpp:187
2 	xul.dll 	nsSocketTransportService::DoPollIteration 	netwerk/base/src/nsSocketTransportService2.cpp:817
3 	xul.dll 	nsSocketTransportService::Run 	netwerk/base/src/nsSocketTransportService2.cpp:645
4 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:612
5 	xul.dll 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:256
6 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:395
7 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:90
8 	msvcr100.dll 	_callthreadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:314
9 	msvcr100.dll 	_threadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292
10 	kernel32.dll 	BaseThreadInitThunk 	
11 	ntdll.dll 	__RtlUserThreadStart 	
12 	ntdll.dll 	_RtlUserThreadStart

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsSocketTransportService%3A%3ADetachSocket%28nsSocketTransportService%3A%3ASocketContext*%2C+nsSocketTransportService%3A%3ASocketContext*%29

Comment 1

[Scoobidiver (away)]

With combined signatures, it's #3 top crasher in today's build.

Comment 2

[Patrick McManus [:mcmanus]]

 bug 766817 landed on aurora on 10/18 - that is also built nightly, right? Crash reports doesn't seem to show any instances of this on 18 while it is prevalent on 19 - so 766817 seems like a less likely cause.

this crash has been on and off on many releases for a while, but something changed in 19 to drive it through the roof.

Comment 3

[Patrick McManus [:mcmanus]]

bug 802378 could be a shot in the dark here.

Comment 4

[Patrick McManus [:mcmanus]]

Brian, how would you feel about backing out 802378 for a couple days just to look at the crash stats? It doesn't look like a critical patch, but I wouldn't know... I don't have a better suggestion at the moment.

The most common form of crash is an exec error at nsSocketTransportService2.cpp:180
    sock->mHandler->OnSocketDetached(sock->mFD);

Probably a corrupt mHandler.

From the regression range here are the things that seem tangentially related:

* two patches of mine 766817 and 785050.. these also went to aurora (ff18) on 10/18 and the crash does not appear on aurora at all. I believe aurora gets pushed out pretty much as quickly as nightly (correct me if I'm wrong). Its not exactly an innocence proof as there could be some other ff19 interaction, but its reasonable doubt :).. these are also corner case code paths that are hard to square with a top crasher (one involves using windows integrated auth and the other websockets that recevied http auth reply of 401 or 407).

* a few rtcweb things.. but that's preffed off and I just have a hard time believing that there is enough use of it to generate that many crashes. But maybe there is a early adopter cult following - I have seen weird bugs generate high ranking crashes before (e.g. I made compilation error in your PAC file crash nightly and that immediately was a top 10 crasher to my surprise) which is a tribute to the general stableness of nightly I suppose.

* 802378 .. my primary suspicion is really just guilt by association.. so its not a strong suspicion. but the patch changes a whole bunch of stuff from nsRefPtr to mozilla::RefPtr. I'm not really clear on what the differences are there (thread safety issues maybe?) but a bad reference count could certainly be at the root of the issue. In its defense it doesn't directly handle the classes in question, but neither does anything in the regression range. and psm certainly is in the mix as an nspr layer.

Comment 5

[Patrick McManus [:mcmanus]]

with brian's go ahead I backed out 802378 as a candidate for causing this.

If that doesn't work we'll test 766817 and 785050.

 https://hg.mozilla.org/integration/mozilla-inbound/rev/82d78390fda1

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/82d78390fda1

Comment 7

[Scoobidiver (away)]

There are no crashes in 19.0a1/20121023. The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1c3e4cb1f754&tochange=48502b61a63e
The backout of bug 802378 landed after this window, so bug 802378 should be pushed again.

Comment 8

[Patrick McManus [:mcmanus]]

(In reply to Scoobidiver from comment #7)
> There are no crashes in 19.0a1/20121023. The working range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=1c3e4cb1f754&tochange=48502b61a63e

weird - but still true now for nightly channel. I've looked at that range and I can't explain it.. some far out possibilities:

* bluetooth changes... I don't think they use the STS poll mechanism, but maybe I'm wrong

* a fix to the necko shutdown logic - that could logically be quire related to the crash signature but that problem has existed for a long time and these crashes are new.. perhaps it fixes an underlying problem for which a trigger was only recently added.

let's close this and reopen if they appear again.


> The backout of bug 802378 landed after this window, so bug 802378 should be
> pushed again.

done.
 https://hg.mozilla.org/integration/mozilla-inbound/rev/9a4531d2d243