Closed Bug 1303804 Opened 5 years ago Closed 5 years ago
Beta builds failing with selftest
.py | XPCShell Tests Tests .test Uncaught Rejection, line 861: Value test _simple _uncaught _rejection .js:3:3 expected in log:
Needinfo-ing someone who recently touched the self tests and someone who reviewed someone who recently touched the self tests.
We have: 08:44:45 WARNING - TEST-UNEXPECTED-FAIL | /builds/slave/m-beta-lx-00000000000000000000/build/src/testing/xpcshell/selftest.py | XPCShellTestsTests.testUncaughtRejection, line 861: Value test_simple_uncaught_rejection.js:3:3 expected in log: 08:44:45 INFO - FAIL: testUncaughtRejection (__main__.XPCShellTestsTests) 08:44:45 INFO - Traceback (most recent call last): 08:44:45 INFO - File "/builds/slave/m-beta-lx-00000000000000000000/build/src/testing/xpcshell/selftest.py", line 861, in testUncaughtRejection 08:44:45 INFO - self.assertInLog("test_simple_uncaught_rejection.js:3:3") 08:44:45 INFO - File "/builds/slave/m-beta-lx-00000000000000000000/build/src/testing/xpcshell/selftest.py", line 494, in assertInLog 08:44:45 INFO - self._assertLog(s, True) 08:44:45 INFO - File "/builds/slave/m-beta-lx-00000000000000000000/build/src/testing/xpcshell/selftest.py", line 488, in _assertLog 08:44:45 INFO - ========""" % (s, "expected" if expected else "not expected", l)) 08:44:45 INFO - AssertionError: Value test_simple_uncaught_rejection.js:3:3 expected in log: Which sounds kind of odd. I'm trying to find out if we have any non-release promise-specific behavior.
We have no only-on-release promise-specific behavior AFAICS. The test that is failing was checked in around six months ago, which suggests that if we *did* have such behavior, we would have noticed it a couple release cycles ago. It would be really nice to see what the log did contain in this case; it's possibly something is going sideways in xpcshell itself? Some sort of environment changes are also a possibility, but since previous tests executed OK, I think it's unlikely that the environment would cause this specific test to fall over.
I didn't look that closely, but the test is expecting an error message containing the substring test_simple_uncaught_rejection.js:3:3 but it's actually getting test_simple_uncaught_rejection.js, line 3: I'm just assuming that we've implemented line number ranges since beta.
Assignee: nobody → sphink
Status: NEW → ASSIGNED
Comment on attachment 8792620 [details] [diff] [review] Test fix for JS engine Promises in beta, error message format change Review of attachment 8792620 [details] [diff] [review]: ----------------------------------------------------------------- It looks like there are several other messages like this that would need fixing as well--if this was the actual cause. (At least, that's what emacs regex search with \.js: said...) ::: testing/xpcshell/selftest.py @@ +857,5 @@ > self.writeManifest(["test_simple_uncaught_rejection.js"]) > > self.assertTestResult(False) > self.assertInLog(TEST_FAIL_STRING) > + self.assertInLog("test_simple_uncaught_rejection.js, line 3:") A brief IRC conversation suggests that any message format changes ought to have showed up by failing this test before we actually got to beta. So this seems unlikely to fix anything?
The push date for https://hg.mozilla.org/mozilla-central/rev/12affc4c78cf was 2016-06-12, which without looking at a calendar feels to me like just right for just now hitting beta.
(In reply to Nathan Froyd [:froydnj] from comment #5) > A brief IRC conversation suggests that any message format changes ought to > have showed up by failing this test before we actually got to beta. So this > seems unlikely to fix anything? I agree with your logic. But I pulled and built, and I can reproduce the failure without this change, and it passes with it. :-) This makes no sense to me, since you're right, there's at least one other test that looks for the same :%d:%d format string, and it's passing for me locally. I'll look at what it's doing.
The :%d:%d format is from stack dumps, which error messages sometimes get. The beta version is not getting the stack dump because mWindowID is 0 because xpc::WindowGlobalOrNull(aPromise) is null because the promises's global is a BackstagePass which gives a null from UNWRAP_OBJECT(Window, aObj, win) because BackstagePass is neither a DOM class nor a wrapper. ...and that means something to somebody, somebody who is not me.
Severity: normal → blocker
Version: Version 3 → 50 Branch
Attachment #8792620 - Attachment is obsolete: true
Comment on attachment 8792692 [details] [diff] [review] Test fix for JS engine Promises in beta, async stacks unavailable Review of attachment 8792692 [details] [diff] [review]: ----------------------------------------------------------------- Thank you for investigating!
Attachment #8792692 - Flags: review?(nfroyd) → review+
(and for the record, the other ones work because they use Error.stack, which will always be present.)
https://hg.mozilla.org/releases/mozilla-beta/rev/b1d6c8c73516 This will still need to land to trunk and hopefully get uplifted to aurora.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/78ceb8466691 Fix Promise test that relies on non-release feature (async stacks), r=froydnj
You need to log in before you can comment on or make changes to this bug.