fix: json gcc runtime error

[andiwand]

I was facing a runtime error at https://github.com/acts-project/acts/blob/main/Plugins/Json/include/Acts/Plugins/Json/GeometryHierarchyMapJsonConverter.hpp#L110

after applying the changes everything is back to normal

looks like a problem with gcc and nlohmann/json?

gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0

[paulgessinger]

Super strange. This is fine to go in obviously, but can you give it a quick try with static constexpr std::string_view by any chance?

[andiwand]

the static constexpr const char* change was actually not critical but I left it in because it think it is more correct?

first I was not even able to print kHeaderKey for example

the critical change was unrolling the initialization list but I really don't know why it caused a runtime error

[HadrienG2]

Note that compiler runtime errors are almost always bugs (barring edge cases like your computer running out of RAM) and should be reported as such to the compiler developers : https://gcc.gnu.org/bugs/

[codecov]

Codecov Report

Merging #1301 (747c0e7) into main (d3bddc9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1301   +/-   ##
=======================================
  Coverage   47.42%   47.42%           
=======================================
  Files         375      375           
  Lines       19788    19788           
  Branches     9287     9287           
=======================================
  Hits         9385     9385           
  Misses       4021     4021           
  Partials     6382     6382           

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[andiwand]

@HadrienG2 I thought it could be due to a bug in the libraryl like UB that turns out okay with clang but not gcc. or they use a language "feature" that does not exist in the standard. not sure how likely those cases are compared to each other tho

[HadrienG2]

@HadrienG2 I thought it could be due to a bug in the libraryl like UB that turns out okay with clang but not gcc. or they use a language "feature" that does not exist in the standard. not sure how likely those cases are compared to each other tho

In this case, the compiler should emit a standard error or warning message following the usual style, like this:

If on the other hand you get an internal compiler error message like the last lines of this:

...then it means the compiler has crashed in a way that was not expected by its developers (hence the absence of a proper error message following the usual style). These errors are the ones that should be reported.

[andiwand]

@HadrienG2 sorry I think I messed things up with my poor PR title. there was not a runtime error while compiling with gcc but a runtime error unfolded when executing Acts compiling with gcc while it works fine with clang

[HadrienG2]

Ah, sorry for misinterpreting on my side as well.

A simple check that is quite effective at discriminating between UB and other issues is to rebuild without optimizations (CMake Debug build or -O0 manual optimization flag). If the runtime error goes away in this configuration, then it's likely to be a UB problem.

[HadrienG2]

...and if the bug is still there at -O0, then you can build with debug symbols (-g, also part of CMake's Debug build), and use GDB to locate the precise point at which the program is crashing, which is often quite helpful.