Closed Bug 1154154 Opened 9 years ago Closed 9 years ago

Intermittent browser_updateid.js | application terminated with exit code -11 | Assertion failure: !aOther.IsNull() (Cannot compute with aOther null value), at ../../../dist/include/mozilla/TimeStamp.h:515

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox38 --- unaffected
firefox39 --- unaffected
firefox40 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: cbook, Assigned: Dexter)

References

()

Details

(Keywords: assertion, crash, intermittent-failure)

Ubuntu VM 12.04 mozilla-inbound debug test mochitest-browser-chrome-3

https://treeherder.mozilla.org/logviewer.html#?job_id=8803197&repo=mozilla-inbound

21:24:12 WARNING - TEST-UNEXPECTED-FAIL | toolkit/mozapps/extensions/test/browser/test-window/browser_updateid.js | application terminated with exit code -11 

21:24:12 INFO - Assertion failure: !aOther.IsNull() (Cannot compute with aOther null value), at ../../../dist/include/mozilla/TimeStamp.h:515
21:24:12 INFO - #01: mozilla::RecordShutdownEndTimeStamp() [xpcom/ds/TimeStamp.h:515]
21:24:12 INFO - #02: XRE_main [toolkit/xre/nsAppRunner.cpp:4472]
21:24:12 INFO - #03: do_main [browser/app/nsBrowserApp.cpp:294]
21:24:12 INFO - #04: main [browser/app/nsBrowserApp.cpp:669]
21:24:12 INFO - TEST-INFO | Main app process: killed by out-of-range signal, number 117
Ugh, something very-recently broke this :(
Component: Add-ons Manager → XPCOM
Flags: needinfo?(nfroyd)
Product: Toolkit → Core
Some semblance of a regression range:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-searchStr=ubuntu%20debug browser-chrome-3&fromchange=4d0b61eb4ae9&tochange=4fc4587d02bf
Ugh, started on a merge. Will have to keep hunting
I think what this assert is saying is that we didn't hit this bit of code earlier:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/nsAppStartup.cpp#380

But why we wouldn't be going through that path intermittently?  Not sure.  Maybe we have a window open at that point, so the loop here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/nsAppStartup.cpp#366

just returns from Quit(), but we wind up shutting down anyway?  I guess that could happen if the chrome process forcibly shuts down the child process?

Are you trying to narrow it down to other trees?  Nothing in that fx-team merge looks suspect.
Flags: needinfo?(nfroyd) → needinfo?(ryanvm)
(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #31)
> Are you trying to narrow it down to other trees?  Nothing in that fx-team
> merge looks suspect.

Not sure I follow. This investigation started on inbound and led to the merge as being when it started, hence why I'm now on fx-team trying to bisect there.
Flags: needinfo?(ryanvm)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #32)
> (In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #31)
> > Are you trying to narrow it down to other trees?  Nothing in that fx-team
> > merge looks suspect.
> 
> Not sure I follow. This investigation started on inbound and led to the
> merge as being when it started, hence why I'm now on fx-team trying to
> bisect there.

That's pretty much what I was asking about. :)  I should have asked whether you were trying to look at things on fx-team instead of what I did.
Retriggers on fx-team confirm this to be a regression from bug 1137252, which was already backed out on inbound for other failure spikes.
https://hg.mozilla.org/integration/mozilla-inbound/rev/6f35b7d9755a
Assignee: nobody → alessio.placitelli
Blocks: 1137252
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
20 green retriggers on the inbound backout push. I think this is confirmed :)
You need to log in before you can comment on or make changes to this bug.