Closed
Bug 1454684
Opened 6 years ago
Closed 5 years ago
Crash in base::Histogram::BucketIndex
Categories
(Toolkit :: Telemetry, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox59 | --- | unaffected |
firefox60 | --- | affected |
People
(Reporter: marcia, Assigned: marcia)
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is report bp-d4136178-c769-40e8-a775-86fbd0180417. ============================================================= Seen while looking at 60 B12 specific crashes: https://bit.ly/2qJZh9N. One crash in b11 and 106 in b12. All AMD processors. Top 10 frames of crashing thread: 0 xul.dll base::Histogram::BucketIndex ipc/chromium/src/base/histogram.cc:297 1 xul.dll `anonymous namespace'::internal_HistogramAdd toolkit/components/telemetry/TelemetryHistogram.cpp:625 2 xul.dll `anonymous namespace'::internal_Accumulate toolkit/components/telemetry/TelemetryHistogram.cpp:1010 3 xul.dll mozilla::net::nsSocketTransportService::Run netwerk/base/nsSocketTransportService2.cpp:930 4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1040 5 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:517 6 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:334 7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:319 8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:299 9 xul.dll nsThread::ThreadFunc xpcom/threads/nsThread.cpp:423 =============================================================
Comment 1•6 years ago
|
||
I looked into this for a bit today. The crashing frame points at an assignment of one local to another: https://searchfox.org/mozilla-central/rev/a30a60eadcff99d2a043241955d215dbeccad876/ipc/chromium/src/base/histogram.cc#297 It was called when nsSocketTransportService called AccumulateTimeDelta for STS_POLL_CYCLE (which never expires). I guess that means the Histogram instance is bogus? There's a MOZ_ASSERT that would have caught it in debug, but if this is timing-sensitive it wouldn't have shown. It's not a startup crash (happened 6min into the session). There's plenty of memory available, so the allocation of the Histogram ought not to have failed (if it needed allocation) This would imply the histogram storage has bogus entries, I guess? I don't know how that would happen or what would exacerbate it in b12.
Assignee | ||
Comment 2•6 years ago
|
||
So far I don't see any crashes in b13.
Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Marcia Knous [:marcia - needinfo? me] from comment #2) > So far I don't see any crashes in b13. Looks as if one user hit is so far in b13.
Comment 4•6 years ago
|
||
Looks like this may be gone?
Assignee: nobody → mozillamarcia.knous
Status: NEW → ASSIGNED
Priority: -- → P1
Assignee | ||
Comment 5•6 years ago
|
||
Another hit in b14, but so far nothing in b15. So we still have crashes, but extremely low volume.
Updated•6 years ago
|
Priority: P1 → P4
Assignee | ||
Comment 6•5 years ago
|
||
Closing this one out as WFM due to trivial volume on all branches.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•