Closed Bug 740315 Opened 13 years ago Closed 13 years ago

crash in nsHttpPipeline::ReadFromPipe @ nsSocketOutputStream::Write

Categories

(Core :: Networking: HTTP, defect)

14 Branch
x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 671468
Tracking Status
firefox14 - ---

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

It's #8 top crasher over the last 3 days. It first appeared in 14.0a1/20120324. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab2ff3b5611f&tochange=df1f94b2bdee The stack is different from the one in bug 671468. Signature nsSocketOutputStream::Write(char const*, unsigned int, unsigned int*) More Reports Search UUID ea3875b8-5dee-444f-934a-097dc2120329 Date Processed 2012-03-29 12:18:10 Uptime 242 Last Crash 3.3 hours before submission Install Age 3.8 hours since version was first installed. Install Time 2012-03-29 08:28:46 Product Firefox Version 14.0a1 Build ID 20120328115525 Release Channel nightly OS Windows NT OS Version 5.1.2600 Service Pack 3 Build Architecture x86 Build Architecture Info GenuineIntel family 15 model 4 stepping 1 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0xa4d1000 App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x0391, AdapterSubsysID: 00000000, AdapterDriverVersion: 6.14.11.7824 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- EMCheckCompatibility True Total Virtual Memory 2147352576 Available Virtual Memory 1918087168 System Memory Use Percentage 68 Available Page File 811696128 Available Physical Memory 168267776 Frame Module Signature Source 0 @0x17202b 1 @0x171e94 2 @0x15fdfd 3 xul.dll nsSocketOutputStream::Write netwerk/base/src/nsSocketTransport2.cpp:587 4 xul.dll nsHttpConnection::OnReadSegment netwerk/protocol/http/nsHttpConnection.cpp:1180 5 xul.dll nsHttpPipeline::ReadFromPipe netwerk/protocol/http/nsHttpPipeline.cpp:675 6 xul.dll nsPipeInputStream::ReadSegments xpcom/io/nsPipe3.cpp:799 7 xul.dll nsHttpPipeline::ReadSegments netwerk/protocol/http/nsHttpPipeline.cpp:719 8 xul.dll nsHttpConnection::OnSocketWritable netwerk/protocol/http/nsHttpConnection.cpp:1238 9 xul.dll nsHttpConnection::OnOutputStreamReady netwerk/protocol/http/nsHttpConnection.cpp:1511 10 xul.dll nsHttpConnection::Activate netwerk/protocol/http/nsHttpConnection.cpp:393 11 xul.dll nsHttpConnectionMgr::DispatchTransaction netwerk/protocol/http/nsHttpConnectionMgr.cpp:1443 12 xul.dll nsHttpConnectionMgr::nsHalfOpenSocket::OnOutputStreamReady netwerk/protocol/http/nsHttpConnectionMgr.cpp:2407 13 xul.dll nsSocketOutputStream::OnSocketReady netwerk/base/src/nsSocketTransport2.cpp:525 14 xul.dll nsSocketTransport::OnSocketReady netwerk/base/src/nsSocketTransport2.cpp:1568 15 xul.dll nsSocketTransportService::DoPollIteration netwerk/base/src/nsSocketTransportService2.cpp:762 16 xul.dll nsSocketTransportService::Run netwerk/base/src/nsSocketTransportService2.cpp:645 17 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:656 18 xul.dll nsThread::ThreadFunc xpcom/threads/nsThread.cpp:289 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 msvcr100.dll _callthreadstartex f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c:314 22 msvcr100.dll _threadstartex f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c:292 23 kernel32.dll BaseThreadStart More reports at: https://crash-stats.mozilla.com/report/list?signature=nsSocketOutputStream%3A%3AWrite%28char+const*%2C+unsigned+int%2C+unsigned+int*%29
I believe this is a dup of 671468 The pipeline checkin has changed the stack signature a little bit, but the underlying issue is unchanged. These are signatures of 671468: https://crash-stats.mozilla.com/report/index/d2ee79fb-63ea-4475-8b30-0a4ce2120411 https://crash-stats.mozilla.com/report/index/a16e952e-fc06-4908-895b-3d5932120411 https://crash-stats.mozilla.com/report/index/f082ff9c-0884-4614-84df-6a3662120411 Fundamentally this is the same codepath except the nsHttpTransaction object has been replaced by a nsHttpPipeline object (which the pipeline checkin did do), but the situation (an onwriteevent) and the action (a segv in actually writing) are the same. So I don't think this is new behavior. Still weird though :(
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Fx 14 also sees a spike of crashes like bp-eb48078d-a2e6-46f8-9a09-21fa42120802 which looks like this same one.
Crash Signature: [@ nsSocketOutputStream::Write(char const*, unsigned int, unsigned int*)] → [@ nsSocketOutputStream::Write(char const*, unsigned int, unsigned int*)] [@ strstr | nsSocketOutputStream::Write(char const*, unsigned int, unsigned int*) ]
You need to log in before you can comment on or make changes to this bug.