windows/aarch64 - TestFloatingPoint.exe | test failed with return code 3221225501
Categories
(Core :: MFBT, defect, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: Waldo)
References
Details
Attachments
(1 file)
#[markdown(off)]
Filed by: egao [at] mozilla.com
https://treeherder.mozilla.org/logviewer.html#?job_id=226927575&repo=try
Observed during win10/aarch64 test run of cppunit.
Context surrounding the failure:
19:08:33 WARNING - TEST-UNEXPECTED-FAIL | WindowsDllInterceptor | Failed to add hook
19:08:33 WARNING - TEST-UNEXPECTED-FAIL | TestDllInterceptor.exe | test failed with return code 1
19:08:33 INFO - TEST-INFO took 59ms
19:08:33 INFO - TEST-START | TestEndian.exe
19:08:33 INFO - TEST-PASS | TestEndian.exe | took 57ms
19:08:33 INFO - TEST-START | TestEnumeratedArray.exe
19:08:33 INFO - TEST-PASS | TestEnumeratedArray.exe | took 73ms
19:08:33 INFO - TEST-START | TestEnumSet.exe
19:08:34 INFO - TEST-PASS | TestEnumSet.exe | took 58ms
19:08:34 INFO - TEST-START | TestEnumTypeTraits.exe
19:08:34 INFO - TEST-PASS | TestEnumTypeTraits.exe | took 59ms
19:08:34 INFO - TEST-START | TestFastBernoulliTrial.exe
19:08:34 INFO - TEST-PASS | TestFastBernoulliTrial.exe | took 85ms
19:08:34 INFO - TEST-START | TestFloatingPoint.exe
19:08:34 WARNING - TEST-UNEXPECTED-FAIL | TestFloatingPoint.exe | test failed with return code 3221225501
19:08:34 INFO - TEST-INFO took 87ms
19:08:34 INFO - TEST-START | TestFunctionTypeTraits.exe
19:08:34 INFO - TEST-PASS | TestFunctionTypeTraits.exe | took 87ms
19:08:34 INFO - TEST-START | TestIntegerPrintfMacros.exe
Updated•6 years ago
|
Comment 1•6 years ago
|
||
:waldo I've been told that you may be able to help with this failure. It was observed as part of win10/aarch64 test run of cppunit from taskcluster.
Assignee | ||
Comment 2•6 years ago
|
||
Plausibly I could, yes -- will need an extra assist on hardware to run/test this on, tho. Sean, any chance you could get me onto the hardware you have to debug through this?
I'm guessing this ought to be straightforward to figure out what's wrong, although I hope it doesn't come down to something like our BitwiseCast operation invoking undefined behavior that is far harder to work around.
Assignee | ||
Updated•6 years ago
|
Comment hidden (Intermittent Failures Robot) |
This is A(pow(2.0, -1074.0) != 0.0);
failing at https://searchfox.org/mozilla-central/rev/cb7faaf6b4ad2528390186f1ce64618dea71031e/mfbt/tests/TestFloatingPoint.cpp#319.
The pow in the system's C runtime is returning 0 for that call. I had reported this to MS a while back and they acknowledged the bug and said they would fix it, but I don't have any information on timeframe.
Updated•6 years ago
|
Assignee | ||
Comment 5•6 years ago
|
||
This is just a test. We could supply our own implementation of exponentiation -- which this test only needs for simple binary powers of two -- and use that, to deal with this.
That wouldn't address bug 1526012, tho.
It's also relatively possible that fdlibm has a pow implementation in it that is correct in these regards, and we could slot in and use that for the JS-visible side of things. That wouldn't help an mfbt test, tho, because fdlibm is JS-side and mfbt does not depend on JS.
Comment hidden (Intermittent Failures Robot) |
Comment 7•6 years ago
|
||
:waldo, :dmajor - I have noticed that as of recent try push here the cppunit
test is showing a green run.
Should this bug be kept open for further investigation or perhaps closed as fixed?
Assignee | ||
Comment 8•6 years ago
|
||
If Microsoft updated their stuff, yeah, I think we're done. I don't know where I'd check to find that out, tho, and I don't know what the real-world update cycle would look like for actual consumers, to say. dmajor?
What happened was in bug 1531388 we picked up a compiler update that optimizes away this call (https://llvm.org/pr40541). I'm pretty sure the OS's pow
is still broken, if we were to call it directly.
So it kind of depends on what this bug is tracking. If it tracks the test failure, resolve it; if it tracks pow being broken, we may want to keep it open. Waldo, any preference?
Comment 10•6 years ago
|
||
Needinfo timeout.
:egao, do whatever you think is reasonable with this bug.
Assignee | ||
Comment 11•6 years ago
|
||
Mm. Let's not scope-creep too hard on this, and let's limit it to this specific test being adequately resilient. The other bug can deal with pow() inadequacies as they affect the other user that induced a bug.
Assignee | ||
Comment 12•6 years ago
|
||
Assignee | ||
Comment 13•6 years ago
|
||
I take https://treeherder.mozilla.org/#/jobs?repo=try&revision=4bd81be0ab811082fd812ba730f94cdd4b45cf9d to be indicating that this change will work out fine in the field, FWIW.
Updated•6 years ago
|
Comment 14•6 years ago
|
||
Comment 15•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Description
•