Open bcoconni opened 3 years ago
When I run the scripts\c172_runway_at_rest_cg_shift.xml
locally here on Windows I don't see the issue. I think I saw you making a comment on one of the commits that you also couldn't reproduce it locally on Windows?
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>
I think I saw you making a comment on one of the commits that you also couldn't reproduce it locally on Windows?
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 scripts\c172_runway_at_rest_cg_shift.xml
with a debugger and check if the variables s12x
or m12x
are close to values that could trigger an FPE: either extremely small or extremely huge. A division by zero or an illegal value seem to be excluded at first since the FPE is raised during multiplications.
Hmm, I wasn't running it from python, I ran jsbsim.exe
directly. Just trying python CheckScripts.py
now it doesn't look like fpectl
is a standard installed module?
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 CheckScipts.py
I'm a bit confused, I don't see c172_runway_at_rest_cg_shift.xml
referenced?
for s in self.script_list(['737_cruise_steady_turn_simplex.xml']):
Just trying
python CheckScripts.py
now it doesn't look likefpectl
is a standard installed module?
The command python CheckScripts.py
should be executed from the tests
folder where the Python modules jsbsim
and fpectl
have been built: it should be something like build/Release/tests
, build/RelWithDebInfo/tests
or build/Debug/test
.
Also looking at
CheckScipts.py
I'm a bit confused, I don't seec172_runway_at_rest_cg_shift.xml
referenced?
Yeah, the test API is poorly designed (who read the tests anyway ? :smile:): the list provided to self.script_list
is actually a blacklist i.e. the list of scripts to be excluded from the test.
https://github.com/JSBSim-Team/jsbsim/blob/11ea52ed340ea32a34e6e3dfc6df503f9ad16cf5/tests/JSBSim_utils.py#L159-L169
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 python CheckScripts.py
in the tests
folder, however I hadn't performed a cmake
build, just the Visual Studio build of the project which only builds jsbsim.exe
.
I guess the line of code would be clearer if
Yep, especially while taking a quick glance at the code while watching the Euros soccer final at the same time! :wink:
Of course, when running the test from build/.../tests
you need to give the relative path to python
: something like
> python ../../../tests/CheckScripts.py
In order to save myself the trouble of all these dots, I generally use the ctest
command from the build directory root (i.e. build/Debug
, build/Release
, etc.)
> ctest -R CheckScript --output-on-failure
The last parameter --output-on-failure
to make sure that the complete test log is only dumped if there is a failure in the test.
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:
s12
and m12
for short lines (all languages).However, in its release v1.51, GeographicLib switched to C++11 math routines rather than using their own:
Math::hypot
, Math::expm1
, Math::log1p
, Math::asinh
, Math::atanh
, Math::copysign
, Math::cbrt
, Math::remainder
, Math::remquo
, Math::round
, Math::lround
, Math::fma
, Math::isfinite
, and Math::isnan
) are now deprecated. Just use the versions in the std:: namespace
instead.SphericalEngine
class, fix the namespace for using streamoff.Math::degree()
, now have default template parameters, T = Math::real.
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 !?!
So how come I didn't see the error when I ran .\Release\JSBSim.exe --script=scripts\c172_runway_at_rest_cg_shift.xml
?
Since I wasn't running it via the python test, rather running the JSBSim.exe
were the set of floating point exceptions that are enabled different?
Floating point exceptions are only raised when the Python module fpectl
is used (which function turnon_sigfpe
sets some CPU flags to send a signal SIGFPE whenever an FPE occurs). Otherwise, FPEs are plainly and simply ignored.
There has just been another occurrence of the bug on the Linux runner: same stack trace than above, script scripts/c1724.xml
.
It smells like there is an uninitialized variable somewhere in GeographicLib code.
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 runner JSBSim: commit 11ea52ed340ea32a34e6e3dfc6df503f9ad16cf5 from themaster
branch. Python: 3.6Other information None