Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 24.94%. Comparing base (13008f3) to head (2ee096c).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1259      +/-   ##
==========================================
- Coverage   24.95%   24.94%   -0.01%     
==========================================
  Files         169      169              
  Lines       19523    19524       +1     
==========================================
  Hits         4871     4871              
- Misses      14652    14653       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Saw some interesting things while trying to reproduce this using Visual Studio.

Running a release build under the debugger, it was hit and miss, every 3rd-4th run would stop with a division by 0 exception.

Exception thrown at 0x00000001400D8F77 in JSBSim.exe: 0xC000008E: Floating-point division by zero (parameters: 0x0000000000000000, 0x0000000000001924).
Unhandled exception at 0x00000001400D8F77 in JSBSim.exe: 0xC000008E: Floating-point division by zero (parameters: 0x0000000000000000, 0x0000000000001924).

However running a debug build under the debugger I never saw a division by 0 exception. But did notice a very consistent pattern in the uninitialized structure.

Note the value of the uninitialized doubles.

Which is more than likely coming from the debug heap used by the debug build of MSVC.

https://www.nobugs.org/developer/win32/debug_crt_heap.html

Where the debug heap returns heap memory with a specific fill pattern which result in an unusual double value.

So at least for debug MSVC builds we could potentially have some asserts looking for these sorts of patterns of uninitialized doubles etc. in various of the heap based structures in JSBSim.

@seanmcleod70, based on your investigations, could you confirm that this PR indeed fixes the reported bug ?

Just confirmed that the debug heap in MSVC fills heap memory it returns with 0xCD, and that 8 bytes of that results in a double with a value of -6.2774385622041925e+66, so a good indicator of an uninitialized member. Also the stack seems to also be filled with 0xCD, so uninitialized local doubles also stand out.

I tested your proposed fix in both debug and release builds and it does the trick.

Just confirmed that the debug heap in MSVC fills heap memory it returns with 0xCD, and that 8 bytes of that results in a double with a value of -6.2774385622041925e+66, so a good indicator of an uninitialized member. Also the stack seems to also be filled with 0xCD, so uninitialized local doubles also stand out.

I have tried adding a test before the computation of HelicalTipMach on Windows in Debug mode:

+  char* p = reinterpret_cast<char*>(&in.Soundspeed);
+  assert(*p != 0xCD);
  HelicalTipMach = sqrt(Vtip*Vtip + Vel*Vel) / in.Soundspeed;

But the assertion did not fail. Not sure what I did wrong ?

I tested your proposed fix in both debug and release builds and it does the trick.

Thanks. PR merged !

But the assertion did not fail. Not sure what I did wrong ?

Hmm, was also stumped for a bit.

  char* p = reinterpret_cast<char*>(&in.Soundspeed);
  char pp = *p;
  assert(*p != 0xCD);

*p != 0xCD
true
*p
0xcd 'Í'
*p != 0xcd
true
*p == 0xcd
false

pp
0xcd 'Í'
pp != 0xCD
true
pp == 0xcd
false
pp == (char)0xcd
true

It's a signed versus unsigned issue.

0xCD = 1100 1101 (205)

Good catch 👍 ! Changing the type to unsigned char* fixed the problem.