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 ]
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.