Beta builds failing with selftest.py | XPCShellTestsTests.testUncaughtRejection, line 861: Value test_simple_uncaught_rejection.js:3:3 expected in log:

RESOLVED FIXED in Firefox 50

Status

defect
--
blocker
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: intermittent-bug-filer, Assigned: sfink)

Tracking

50 Branch
mozilla52
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox50 fixed, firefox51 fixed, firefox52 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Needinfo-ing someone who recently touched the self tests and someone who reviewed someone who recently touched the self tests.
Flags: needinfo?(ted)
Flags: needinfo?(nfroyd)
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.
Flags: needinfo?(nfroyd)
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.
Attachment #8792620 - Flags: review?(nfroyd)
Assignee: nobody → sphink
Status: NEW → ASSIGNED
Flags: needinfo?(ted)
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?
Attachment #8792620 - Flags: review?(nfroyd)
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
Ugh. Turned out to be simple.

We're looking for the promise's stack. The stack is only filled in if javascript.options.asyncstack is set, and it isn't if RELEASE_BUILD. http://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#1231

I don't know why the JSM version is able to provide the stack.
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 sfink@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/78ceb8466691
Fix Promise test that relies on non-release feature (async stacks), r=froydnj
https://hg.mozilla.org/mozilla-central/rev/78ceb8466691
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.