1718066 - Crash in [@ mozilla::nsRFPService::ReduceTimePrecisionImpl]

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Sean Feng [:sefeng]]

Crash report: https://crash-stats.mozilla.org/report/index/e263afb5-b450-4264-a3c3-3a6b00210622

Reason: EXC_ARITHMETIC / EXC_I386_DIV

Top 10 frames of crashing thread:

0 XUL mozilla::nsRFPService::ReduceTimePrecisionImpl toolkit/components/resistfingerprinting/nsRFPService.cpp:399
1 XUL mozilla::nsRFPService::ReduceTimePrecisionAsUSecsWrapper toolkit/components/resistfingerprinting/nsRFPService.cpp:484
2 XUL NowAsMillis js/src/jsdate.cpp:1512
3 XUL js::date_now js/src/jsdate.cpp:1551
4  @0x2684e6b804af 
5  @0x11f12e18f 
6  @0x2684e6b7cdb2 
7  @0x2b86e001f 
8  @0x2684e6b3956e 
9 XUL js::jit::MaybeEnterJit js/src/jit/Jit.cpp:207

Comment 1

[Sean Feng [:sefeng]]

The spikes in recently Nightlies look concerning. Do you mind take a look Tom?

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

So these are content processes crashes primarily on OSX. (48 out of 52)

EXC_I386_DIV is divide by zero. It's happening on a line calling nsRFPService::RandomMidpoint. foo % 0 will also cause this exception.

*aMidpointOut = rng.next() % aResolutionUSec; is within that function, and seems to be the only candidate. If it were zero though, I would expect such an error earlier. e.g. ong long clamped = floor(double(timeAsInt) / resolutionAsInt) * resolutionAsInt;

I'll post a patch but I don't really understand how we might wind up here or what we should do to address this problem.

Comment 3

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: Bug 1718066: Add a check against zero r?sefeng

I don't see why this is needed or how we got to this place
but we are getting some divide-by-zero errors and maybe
this will resolve them?

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9e460c28eed
Add a check against zero r=sefeng

Comment 5

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/b9e460c28eed