-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating Point Exception in Actions build process #475
Comments
When I run the PS C:\source\jsbsim> .\Release\JSBSim.exe --script=scripts\c172_runway_at_rest_cg_shift.xml
...
...
------------------------------------------------------------------
State Report at sim time: 0.000000 seconds
Position
ECI: -1329521.725534581, -14711849.15995605, 14771801.97958151 (x,y,z, in ft)
ECEF: -1329521.725535 , -14711849.159956 , 14771801.979582 (x,y,z, in ft)
Local: 45.192423, -95.163839, 4.600026 (geodetic lat, lon, alt ASL in deg and ft)
Orientation
ECI: -180, -44.80757682585688, 84.836161 (phi, theta, psi in deg)
Local: -5.264532060613332e-16, -1.590277340731758e-15, 8.20496608763031e-15 (phi, theta, psi in deg)
Velocity
ECI: 1072.80495937053, -96.95025317596601, 0 (x,y,z in ft/s)
ECEF: 0, 0, 0 (x,y,z in ft/s)
Local: 0.000000 , 0.000000 , 0.000000 (n,e,d in ft/sec)
Body: 0.000000 , 0.000000 , 0.000000 (u,v,w in ft/sec)
Body Rates (relative to given frame, expressed in body frame)
ECI: 0.002944405985131796, -4.638594100204067e-19, -0.002964249795347291 (p,q,r in deg/s)
ECEF: 0, 0, 0 (p,q,r in deg/s)
---- JSBSim Execution beginning ... --------------------------------------------
Start: Sunday July 11 2021 21:44:18 (HH:MM:SS)
0: GEAR_CONTACT: 0 seconds: Nose Gear 1
1: GEAR_CONTACT: 0.091663 seconds: Left Main Gear 1
2: GEAR_CONTACT: 0.091663 seconds: Right Main Gear 1
Shift weight (Event 0) executed at time: 1.508273
End: Sunday July 11 2021 21:44:18 (HH:MM:SS)
PS C:\source\jsbsim> |
Indeed, the test completes successfully for me on Linux and Windows. It only fails when the test is executed on GitHub host runners for MSVC. Most likely there is a combination of criteria that are met on GitHub and which do not exist on our PC. May be the version of Python ? It's 3.6 on GitHub while being 3.7 on my Windows PC and 3.9 on my Linux PC. At the moment, there is no reason to discard this problem as being a mere coincidence. Especially since the failure is reproducing repeatedly at each build which IMHO indicates that it is a genuine bug. |
At some point later this week, I intend to run |
Hmm, I wasn't running it from python, I ran PS C:\source\jsbsim\tests> python .\CheckScripts.py
Traceback (most recent call last):
File ".\CheckScripts.py", line 23, in <module>
import fpectl
ModuleNotFoundError: No module named 'fpectl' Also looking at for s in self.script_list(['737_cruise_steady_turn_simplex.xml']): |
The command
Yeah, the test API is poorly designed (who read the tests anyway ? 😄): the list provided to Lines 159 to 169 in 11ea52e
I guess the line of code would be clearer if it would be written like so: - for s in self.script_list(['737_cruise_steady_turn_simplex.xml']):
+ for s in self.script_list(blacklist=['737_cruise_steady_turn_simplex.xml']): |
Ah, I did run
Yep, especially while taking a quick glance at the code while watching the Euros soccer final at the same time! 😉 |
Of course, when running the test from > python ../../../tests/CheckScripts.py In order to save myself the trouble of all these dots, I generally use the > ctest -R CheckScript --output-on-failure The last parameter |
It finally happened to be a genuine bug which was located is our dependency GeographicLib. It has been fixed in the release v1.52 of GeographicLib:
However, in its release v1.51, GeographicLib switched to C++11 math routines rather than using their own:
So it may be that Microsoft (i.e. stdlib) C++11 math functions are better handling the subtleties of floating point arithmetic than GeographicLib's !?! |
Update GeographicLib to version 1.52 to fix issue JSBSim-Team#475. (JSBSim-Team#477)
So how come I didn't see the error when I ran Since I wasn't running it via the python test, rather running the |
Floating point exceptions are only raised when the Python module |
There has just been another occurrence of the bug on the Linux runner: same stack trace than above, script |
I think I have finally isolated the cause of this issue: it seems it is indeed due to an uninitialized variable. I have submitted an issue to GeographicLib geographiclib/geographiclib#33 so that the author can confirm or infirm my findings. I will update JSBSim according to the conclusions of the issue submitted to GeographicLib. |
This avoids the tests to fail because an FPE can be randomly triggered.
Following the answer from GeographicLib (see geographiclib/geographiclib#33 (comment)), I have submitted the PR #1173. Basically, the author of GeographicLib confirmed that the variable However, that is not the strategy that has been chosen here since this would keep the floating point exceptions (FPE) to be triggered. Worse, the FPE would be triggered on every platforms in 100% of the cases which is the exact opposite of the result that is being sought in this issue. |
I'm submitting a ...
Describe the issue
The build for MSVC repeatedly fails while executing the test
CheckScripts.py
and more specifically while running the scriptc172_runway_at_rest_cg_shift.xml
.What is the current behavior?
The test reports an FPE (Floating Point Exception) which seems to be located in the waypoint/geodetic computations code.
Here is the stack trace as reported by the test failure:
What is the expected behavior?
All the tests to run successfully.
What is the motivation / use case for changing the behavior?
N/A
Please tell us about your environment:
OS: GitHub Actions
windows-latest
host runnerJSBSim: commit 11ea52e from the
master
branch.Python: 3.6
Other information
None
The text was updated successfully, but these errors were encountered: