orbitersim / orbiter

I can't reproduce this. Can you give more details?

If I open Extras -> Celestial Body Configuration -> Atmosphere Config, and select a different atmosphere or a different planet from the menu, I get.

Unhandled exception thrown: read access violation.
this was 0x39FF10A0 (or some other random hex)

at

orbiter/Src/Orbiter/TabExtra.cpp

Line 1666 in 85e9a3c

return true;

or

orbiter/Src/Plugin/LaunchpadExtensions/AtmConfig/AtmConfig.cpp

Line 148 in 0326e4d

if (!celbody[0]) return; // nothing to do

Where the access violation occurs (I've only seen it happen at those two places above), appears to be random, at least insofar as I've been able to repeat the bug. It does happen every time I use the atmosphere config dialogue though.

This happens seemingly irrespective of any particular modules (including graphics clients) being loaded or not.

Let me know what I can test on my end

The only thing I can think of is a buffer overrun during construction of a search path. Do you have a particularly long path to your orbiter installation?

Are you in a position to compile a debug version of Orbiter and run under the VS debugger? That might help pinpointing where any overrun happens.

The path I'm executing Orbiter from is "C:\Orbiter\orbiter\out\install\x64-Debug\Orbiter"

Unfortunately, this is about all I'm getting from the debugger:

It looks like the last change to AtmConfig.cpp was commit d2d15ad where a bunch of 32 bit types (as pointers) got changed to 64 bit types. Is it possible that there is some 32 bit variable hiding here that's causing problems. or some intptr_t/uintptr_t pr INT_PTR/LONG_PTR problem?

Hm, possibly, but since I can't reproduce this, it will be difficult for me to debug. Since this appears to happen on access to the "celbody" string, which is a data member of the AtmConfig object, could you check if this string (or indeed the entire "this" object) gets corrupted at any point? Maybe put a data breakpoint on celbody and see if gets overwritten when it shouldn't?

hmmmm okay. So the celbody string is "Earth\0" on opening when makes sense.
If I set a breakpoint on if (!celbody[0]) return; // nothing to do :

It sometimes "this" is 0xFFFFFFFF9E0F2490 or something else very high in the 64 bit space....

If I change SetWindowLongPtr (hWnd, DWLP_USER, (LONG)lParam);
to SetWindowLongPtr (hWnd, DWLP_USER, (LONG_PTR)lParam);

The issue is gone. so it looks like a case of long vs long long

I can make a PR for this fix.

Attempting to change the Atmosphere Config causes access violations