Closed Bug 895931 Opened 8 years ago Closed 8 years ago

Firefox for Android often warns about max sane launch timestamps

Categories

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

All
Android
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kats, Assigned: rnewman)

Details

(Whiteboard: [status-firefox23: fixed][status-firefox24: fixed])

Attachments

(2 files)

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.
Been meaning to file this myself for a while. Shouldn't be happening at all!
Component: General → Product Announcements
Product: Firefox for Android → Android Background Services
The issue here is that GlobalConstants.BUILD_TIMESTAMP is in seconds when it should be in milliseconds.
https://github.com/mozilla-services/android-sync/pull/333
Assignee: nobody → rnewman
Severity: normal → major
Status: NEW → ASSIGNED
Flags: needinfo?(nalexander)
Summary: Firefox for Android often warnings about max same launch timestamps → Firefox for Android often warns about max sane launch timestamps
Attached patch Fix. v1Splinter Review
Nick, any chance you could land this when inbound builds successfully? I'm on PTO this afternoon.
Attachment #778617 - Flags: review+
(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.
Flags: needinfo?(nalexander)
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.
Attachment #778617 - Flags: approval-mozilla-beta?
Attachment #778617 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/145bfcabd9a4
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
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.
Attachment #778617 - Flags: approval-mozilla-beta?
Attachment #778617 - Flags: approval-mozilla-beta+
Attachment #778617 - Flags: approval-mozilla-aurora?
Attachment #778617 - Flags: approval-mozilla-aurora+
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.
This seems to imply it did:

$ hg log -r 'ancestor(5ceea82a79c7,145bfcabd9a4)'
changeset:   139313:145bfcabd9a4
user:        Richard Newman <rnewman@mozilla.com>
date:        Fri Jul 19 13:59:42 2013 -0700
summary:     Bug 895931 - Firefox for Android often warns about max sane launch timestamps. r=nalexander
Yeah, I see that. But it's a really simple patch!
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.
That was my guess, too. I have a local build going with some extra Ls.
This needs to chase the previous fix. I've tested this and also wrote an automated sanity test in the android-sync repo.
Attachment #779955 - Flags: approval-mozilla-beta?
Attachment #779955 - Flags: approval-mozilla-aurora?
Reopening and setting checkin-needed, 'cos inbound is closed and the bug ain't fixed :)
Status: RESOLVED → REOPENED
Keywords: checkin-needed
Resolution: FIXED → ---
Whiteboard: [status-firefox23:fixed][status-firefox24:fixed]
https://hg.mozilla.org/integration/mozilla-inbound/rev/356034879b0b
Status: REOPENED → ASSIGNED
Keywords: checkin-needed
Whiteboard: [uplift needed after landing in Nightly]
Target Milestone: Firefox 25 → ---
https://hg.mozilla.org/mozilla-central/rev/356034879b0b
Status: ASSIGNED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Comment on attachment 779955 [details] [diff] [review]
Trivial follow up to avoid overflow.

Carrying over a+ from earlier.
Attachment #779955 - Flags: approval-mozilla-beta?
Attachment #779955 - Flags: approval-mozilla-beta+
Attachment #779955 - Flags: approval-mozilla-aurora?
Attachment #779955 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/f61ece780449
https://hg.mozilla.org/releases/mozilla-beta/rev/51ef625ce331
Whiteboard: [uplift needed after landing in Nightly] → [status-firefox23: fixed][status-firefox24: fixed]
You need to log in before you can comment on or make changes to this bug.