Closed
Bug 740315
Opened 13 years ago
Closed 13 years ago
crash in nsHttpPipeline::ReadFromPipe @ nsSocketOutputStream::Write
Categories
(Core :: Networking: HTTP, defect)
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
Updated•13 years ago
|
Comment 1•13 years ago
|
||
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
Updated•13 years ago
|
Comment 2•12 years ago
|
||
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.
Description
•