Closed Bug 627579 Opened 14 years ago Closed 8 years ago

Firefox 4.0b10pre Crash [@ nsHttpTransaction::HandleContent(char*, unsigned int, unsigned int*, unsigned int*) ]

Categories

(Core :: Networking: HTTP, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox6 - ---
blocking2.0 --- -

People

(Reporter: marcia, Unassigned)

References

Details

(Keywords: crash, regression, Whiteboard: [necko-backlog])

Crash Data

Seen while reviewing crash stats. Low volume Crashes started showing up using the 2011012000 build. http://tinyurl.com/4hdel7k to the crashes so far.

Possible pushlog regression: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e807269acaa3&tochange=efbf1fa4c70e

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsHttpTransaction::HandleContent 	netwerk/protocol/http/nsHttpTransaction.cpp:984
1 	xul.dll 	nsHttpTransaction::ProcessData 	netwerk/protocol/http/nsHttpTransaction.cpp:1122
2 	xul.dll 	nsHttpTransaction::WritePipeSegment 	netwerk/protocol/http/nsHttpTransaction.cpp:503
3 	xul.dll 	nsPipeOutputStream::WriteSegments 	xpcom/io/nsPipe3.cpp:1137
4 	xul.dll 	nsHttpTransaction::WriteSegments 	netwerk/protocol/http/nsHttpTransaction.cpp:521
5 	xul.dll 	nsHttpConnection::OnSocketReadable 	netwerk/protocol/http/nsHttpConnection.cpp:701
6 	xul.dll 	nsHttpConnection::OnInputStreamReady 	netwerk/protocol/http/nsHttpConnection.cpp:800
7 	xul.dll 	nsSocketInputStream::OnSocketReady 	netwerk/base/src/nsSocketTransport2.cpp:256
8 	xul.dll 	nsSocketTransport::OnSocketReady 	netwerk/base/src/nsSocketTransport2.cpp:1526
9 	xul.dll 	nsSocketTransportService::DoPollIteration 	netwerk/base/src/nsSocketTransportService2.cpp:687
10 	xul.dll 	nsSocketTransportService::OnProcessNextEvent 	netwerk/base/src/nsSocketTransportService2.cpp:551
11 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:597
12 	xul.dll 	NS_ProcessPendingEvents_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:200
13 	xul.dll 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:250
14 	xul.dll 	nsSocketTransportService::Run 	netwerk/base/src/nsSocketTransportService2.cpp:594
15 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
16 	xul.dll 	xul.dll@0xce5c6b 	
17 	xul.dll 	nsThreadStartupEvent::`vector deleting destructor' 	
18 	xul.dll 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:278
19 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:426
20 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:122
21 	mozcrt19.dll 	_callthreadstartex 	obj-firefox/memory/jemalloc/crtsrc/threadex.c:348
22 	mozcrt19.dll 	_threadstartex 	obj-firefox/memory/jemalloc/crtsrc/threadex.c:326
23 	kernel32.dll 	BaseThreadStart
engine@conduit.com may be implicated in this crash. chofmann can we dredge up all the crashes that have that installed?
No obvious HTTP changes there, but at least once cache change...
blocking2.0: --- → ?
Keywords: regression
yeah dups of some crashes are a known problem,  tracking dup submission occurrences in Bug 579136
Depends on: 579136
Not blocking unless this rises significantly in volume.
blocking2.0: ? → -
Crash Signature: [@ nsHttpTransaction::HandleContent(char*, unsigned int, unsigned int*, unsigned int*) ]
yeah, low volume residual crash on older builds, but spiking hard.

are there any recent checkins for code on the stack.
         nsHttpTransaction::HandleContent.char...unsigned.int,.unsigned.int...unsigned.int..
date     total    breakdown by build
         crashes  count build, count build, ...

20110620 7  	5 4.0b52010083108, 
        		2 3.6.172011042014, 
20110621 3 4.0.12011041322 	3 , 
20110622 52  	51 6.0a22011062104, 
        		1 4.0.12011041322,
This looks like it spiked on 2011062100 with 55 crashes, but since then it has been very low volume.
For some reason there was a spike but I can't find any since 06/23/2011. Unless we can correlate this to a prolonged spike, probably not worth tracking.
On Win the recorded crash line is often a next executable line from the line where the crash actually happened.  I think the crash could be because mConnection member on transaction could be broken or more likely null.  Not sure this can happen but should be easy to trace that first.
Crash Signature: [@ nsHttpTransaction::HandleContent(char*, unsigned int, unsigned int*, unsigned int*) ] → [@ nsHttpTransaction::HandleContent(char*, unsigned int, unsigned int*, unsigned int*) ] [@ nsHttpTransaction::HandleContent ]
https://crash-stats.mozilla.com/report/index/2930c356-e3da-48ab-b74f-5b66b2160204

low # (5) of these in crash stats
Whiteboard: [necko-backlog]
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year) in Firefox (except obsolete Fx <23).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.