Closed Bug 1454684 Opened 6 years ago Closed 5 years ago

Crash in base::Histogram::BucketIndex

Categories

(Toolkit :: Telemetry, defect, P4)

60 Branch
x86
Windows 7
defect

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

=============================================================
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.
So far I don't see any crashes in b13.
(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.
Looks like this may be gone?
Assignee: nobody → mozillamarcia.knous
Status: NEW → ASSIGNED
Priority: -- → P1
Another hit in b14, but so far nothing in b15. So we still have crashes, but extremely low volume.
Priority: P1 → P4
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.