Closed Bug 1526507 Opened 8 months ago Closed 7 months ago

windows/aarch64 - TestFloatingPoint.exe | test failed with return code 3221225501


(Core :: MFBT, defect, P5)




Tracking Status
firefox68 --- fixed


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




(1 file)

Filed by: egao [at]

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

: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.

Flags: needinfo?(jwalden)

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.

Flags: needinfo?(sstangl)
Component: mozglue → MFBT
Flags: needinfo?(jwalden)

This is A(pow(2.0, -1074.0) != 0.0); failing at

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.

Flags: needinfo?(sstangl)
See Also: → 1526012

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.

: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?

Flags: needinfo?(jwalden)
Flags: needinfo?(dmajor)

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?

Flags: needinfo?(jwalden)

What happened was in bug 1531388 we picked up a compiler update that optimizes away this call ( 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?

Flags: needinfo?(dmajor) → needinfo?(jwalden)

Needinfo timeout.

:egao, do whatever you think is reasonable with this bug.

Flags: needinfo?(jwalden)

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.

I take to be indicating that this change will work out fine in the field, FWIW.

Attachment #9052659 - Attachment description: Bug 1526507 - Use std::exp2(n) instead of pow(2.0, n) in TestFloatingPoint.cpp to be (hopefully) more resilient against standard library imprecision in the latter. r=dmajor → Bug 1526507 - Use std::exp2{,f}(n) instead of pow{,f}(2.0, n) in TestFloatingPoint.cpp to be (hopefully) more resilient against standard library imprecision in the latter. r=dmajor
Pushed by
Use std::exp2{,f}(n) instead of pow{,f}(2.0, n) in TestFloatingPoint.cpp to be (hopefully) more resilient against standard library imprecision in the latter.  r=dmajor
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee: nobody → jwalden
Blocks: 1539241
You need to log in before you can comment on or make changes to this bug.