Property variable name missing from device exception message under linux release with seatbelts

[ptheywood]

DeviceExceptions thrown for environemnt properties that do not exist do not always print the message variable in the exception string.

This only appears to affect Release builds under linux with (SEATBELTS=ON).

E.g. the Test DeviceExceptionTest.DeviceEnvironmentGetUnknownProperty should throw an exception with the following error message, which it does under debug builds on linux:

First error:
/home/ptheywood/code/flamegpu/FLAMEGPU2/include/flamegpu/runtime/utility/DeviceEnvironment.cuh(143)[0,0,0][0,0,0]:
Environment property with name: nope was not found.

But for Release builds (with SEATBELTS) it throws:

/home/ptheywood/code/flamegpu/FLAMEGPU2/include/flamegpu/runtime/utility/DeviceEnvironment.cuh(143)[0,0,0][0,0,0]:
Environment property with name:  was not found.

To quickly enable the output in all build modes (but break the test suite) run in test_device_exception.cu can be modified to the following:

    void run(int steps = 2) {
        // CudaModel must be declared here
        // As the initial call to constructor fixes the agent population
        // This means if we haven't called model.newAgent(agent) first
        CUDASimulation cudaSimulation(model);
        cudaSimulation.SimulationConfig().steps = steps;
        // This fails as agentMap is empty
        AgentVector population(agent, 1);
        cudaSimulation.setPopulationData(population);
        try {
            cudaSimulation.simulate();
        } catch (const exception::DeviceError& e) {
            printf("%s\n", e.what());
        } 
    }

Then rebuild the test suite and run

./bin/Release/tests --gtest_filter="DeviceExceptionTest.DeviceEnvironmentGetUnknownProperty"

Ideally we should add a test which checks the error message string is correct, otherwise this could be re-introduces in the future.
It is likely this occurs for other types of device exception too.

This was highlighted by Kenneth.

[Robadob]

Looked into this.

My best guess would be it stems from this code block.

There's already an exception for RTC, where char* is explicit templated.

My guess would be that (at one time) RTC was always built as release, and release builds treat string literal as char* rather than char[]. Trying to repro on Windows atm to test and fix.

[Robadob]

So it's the same for release x SEATBELTS=ON, on Windows too. Will hopefully fix this by the end of the day in time for next release.

[Robadob]

So I've now investigated this and solved it locally, PR coming soon.

In summary, the above functions are marked for compilation by RTC, or when included by FLAMEGPUDeviceException.cu. Otherwise, when the host compiler includes this header, it complains about CUDA intrinsics not existing.

My belief is that, this means when other files wish to compile a DeviceException include, they don't see the explicit template and just use the generic, leading to the bug.

Debug builds must report string literals as char[], hence unaffected by the bug.

The fix is instead to mark both functions as inline and wrap them with #ifdef __CUDACC__ instead.