895931 - Firefox for Android often warns about max sane launch timestamps

Status: RESOLVED FIXED

(Android Background Services Graveyard :: Product Announcements, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

I often see this (or equivalent) in logcats I get from people:

W GeckoLogger: fennec_aurora :: AnnounceBrSvc :: Launch time 1374235117536 is later than max sane launch timestamp 127518136746. Ignoring until clock is corrected.

This particular one is in the logcat in the JSON dump at https://crash-stats.mozilla.com/report/index/01cae98c-04ee-4ef0-9b05-322d22130719

It seems to me like this shouldn't happen so often, so I'm filing this bug for investigation. A quick look makes me think that the GlobalConstants.BUILD_TIMESTAMP value is in seconds but being used as milliseconds.

Comment 1

[Richard Newman [:rnewman]]

Been meaning to file this myself for a while. Shouldn't be happening at all!

Comment 2

[Richard Newman [:rnewman]]

The issue here is that GlobalConstants.BUILD_TIMESTAMP is in seconds when it should be in milliseconds.

Comment 3

[Richard Newman [:rnewman]]

https://github.com/mozilla-services/android-sync/pull/333

Comment 4

[Richard Newman [:rnewman]]

Attachment: Fix. v1

Nick, any chance you could land this when inbound builds successfully? I'm on PTO this afternoon.

Comment 5

[Nick Alexander :nalexander [he/him]]

(In reply to Richard Newman [:rnewman] from comment #4)
> Created attachment 778617 [details] [diff] [review]
> Fix. v1
> 
> Nick, any chance you could land this when inbound builds successfully? I'm
> on PTO this afternoon.

I expect to land this today.

Comment 6

[Nick Alexander :nalexander [he/him]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/145bfcabd9a4

Comment 7

[Richard Newman [:rnewman]]

Comment on attachment 778617 [details] [diff] [review]
Fix. v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
  Original landing of Product Announcements.

User impact if declined: 
  No broadcasts.

Testing completed (on m-c, etc.): 
  Just hit inbound. Will bake for a while, but this bug component is lacking tracking flags...

Risk to taking this patch (and alternatives if risky): 
  Should be slim.

String or IDL/UUID changes made by this patch:
  None.

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/145bfcabd9a4

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 778617 [details] [diff] [review]
Fix. v1

In lieu of tracking flags, I'll just make a note for myself to come back and make sure this landed to FF23.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0b9fd9d3446d
https://hg.mozilla.org/releases/mozilla-beta/rev/5c46eea500a8

Comment 11

[Richard Newman [:rnewman]]

I have a Nightly from this morning, and this is still occurring in a way that makes no sense at all. I'm going to assume that this commit didn't make it into the Nightly.

If I have time I'll try on an inbound build.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

This seems to imply it did:

$ hg log -r 'ancestor(5ceea82a79c7,145bfcabd9a4)'
changeset:   139313:145bfcabd9a4
user:        Richard Newman <[e-mail]>
date:        Fri Jul 19 13:59:42 2013 -0700
summary:     Bug 895931 - Firefox for Android often warns about max sane launch timestamps. r=nalexander

Comment 13

[Richard Newman [:rnewman]]

Yeah, I see that. But it's a really simple patch!

Comment 14

[Kartikaya Gupta (email:[e-mail])]

My best guess is one of those multiplications is overflowing.

On my build with the latest nightly the "max sane" timestamp is 126332179280, which is not a reasonable value either in msec or seconds.

Comment 15

[Richard Newman [:rnewman]]

That was my guess, too. I have a local build going with some extra Ls.

Comment 16

[Richard Newman [:rnewman]]

Attachment: Trivial follow up to avoid overflow.

This needs to chase the previous fix. I've tested this and also wrote an automated sanity test in the android-sync repo.

Comment 17

[Richard Newman [:rnewman]]

Reopening and setting checkin-needed, 'cos inbound is closed and the bug ain't fixed :)

Comment 18

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/356034879b0b

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/356034879b0b

Comment 20

[bhavana bajaj [:bajaj]]

Comment on attachment 779955 [details] [diff] [review]
Trivial follow up to avoid overflow.

Carrying over a+ from earlier.

Comment 21

[Richard Newman [:rnewman]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f61ece780449
https://hg.mozilla.org/releases/mozilla-beta/rev/51ef625ce331