Also posted on /micmac-V2/MMVII
I have no idea which project is the reference one.
I have a segmentation fault during compilation.
my environment:
Ubuntu 26.04
cmake version 4.2.3
clang 21.1.8
I ran:
mkdir build && cd build
CC=clang CXX=clang++ cmake ..
make full -j4
I get:
segmentation fault, core dumped.
I enabled sanitization to find the error by running:
mkdir build && cd build
CC=clang CXX=clang++ cmake ..
-DCMAKE_BUILD_TYPE=Debug
-DCMAKE_CXX_FLAGS="-Og -g3 -fno-omit-frame-pointer -fsanitize=address,undefined -fno-sanitize-recover=all"
-DCMAKE_C_FLAGS="-Og -g3 -fno-omit-frame-pointer -fsanitize=address,undefined -fno-sanitize-recover=all"
make -j$(nproc)
ASAN_OPTIONS=abort_on_error=1:disable_coredump=0 ../bin/MMVII
which returned:
`
AddressSanitizer:DEADLYSIGNAL
==29477==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7ec5457796e8 bp 0x7ffc7ea83870 sp 0x7ffc7ea83850 T0)
==29477==The signal is caused by a READ memory access.
==29477==Hint: address points to the zero page.
#0 0x7ec5457796e8 in void std::__cxx11::basic_string<char, std::char_traits, std::allocator>::_M_construct(char const*, unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x1796e8) (BuildId: 3a7a8c6bd922e6314edb7a710fdc0293265c2c42)
#1 0x5ee7c4d31d07 in std::pair<MMVII::eTySC const, std::__cxx11::basic_string<char, std::char_traits, std::allocator>>::pair<MMVII::eTySC, std::__cxx11::basic_string<char, std::char_traits, std::allocator> const&, true>(MMVII::eTySC&&, std::__cxx11::basic_string<char, std::char_traits, std::allocator> const&) /usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15/bits/stl_pair.h:902:35
#2 0x5ee7c4d31d07 in __cxx_global_var_init.37 /home/user/applications/MMVII/src/Serial/ElemStrToVal.cpp:213:28
#3 0x5ee7c4d31d07 in _GLOBAL__sub_I_ElemStrToVal.cpp /home/user/applications/MMVII/src/Serial/ElemStrToVal.cpp
#4 0x7ec54522a793 in call_init csu/../csu/libc-start.c:145:3
#5 0x7ec54522a793 in __libc_start_main csu/../csu/libc-start.c:347:5
#6 0x5ee7c4d56834 in _start (/home/user/applications/MMVII/bin/MMVII+0x64f834) (BuildId: 55945b601813b3db1fb38ef999fa38dda9333a6f)
==29477==Register values:
rax = 0x00007ac539503808 rbx = 0x00007ac5395037f8 rcx = 0x0000000000000000 rdx = 0x0000000000000001
rdi = 0x00007ac539503808 rsi = 0x0000000000000000 rbp = 0x00007ffc7ea83870 rsp = 0x00007ffc7ea83850
r8 = 0x0000000000000000 r9 = 0x00007c553a1eaf80 r10 = 0x00000f66a743d41d r11 = 0x0000000000000000
r12 = 0x00007ac5395037f0 r13 = 0x00007ac539503040 r14 = 0x00000f5927298000 r15 = 0x0000000000000000
`
Using some AI help, I came to the file:
MMVII/src/Serial/ElemStrToVal.cpp
where there is a default init of a string using a null ptr:
template<> cE2Str<eTySC>::tMapE2Str cE2Str<eTySC>::mE2S { {eTySC::NonInit,MMVII_NONE}, {eTySC::US,"unordered"}, };
to be sure I replaced the NULL default by an empty string.
template<> cE2Str<eTySC>::tMapE2Str cE2Str<eTySC>::mE2S { {eTySC::NonInit,""}, {eTySC::US,"unordered"}, };
Then it compiled successfully and at least it runs without the seg fault.
I have no idea of the deep implication of my change !
I haven't addressed the root cause. It was a quick and dirty fix to identify the problem.
Also posted on /micmac-V2/MMVII
I have no idea which project is the reference one.
I have a segmentation fault during compilation.
my environment:
Ubuntu 26.04
cmake version 4.2.3
clang 21.1.8
I ran:
mkdir build && cd build
CC=clang CXX=clang++ cmake ..
make full -j4
I get:
segmentation fault, core dumped.
I enabled sanitization to find the error by running:
mkdir build && cd build
CC=clang CXX=clang++ cmake ..
-DCMAKE_BUILD_TYPE=Debug
-DCMAKE_CXX_FLAGS="-Og -g3 -fno-omit-frame-pointer -fsanitize=address,undefined -fno-sanitize-recover=all"
-DCMAKE_C_FLAGS="-Og -g3 -fno-omit-frame-pointer -fsanitize=address,undefined -fno-sanitize-recover=all"
make -j$(nproc)
ASAN_OPTIONS=abort_on_error=1:disable_coredump=0 ../bin/MMVII
which returned:
`
AddressSanitizer:DEADLYSIGNAL
==29477==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7ec5457796e8 bp 0x7ffc7ea83870 sp 0x7ffc7ea83850 T0)
==29477==The signal is caused by a READ memory access.
==29477==Hint: address points to the zero page.
#0 0x7ec5457796e8 in void std::__cxx11::basic_string<char, std::char_traits, std::allocator>::_M_construct(char const*, unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x1796e8) (BuildId: 3a7a8c6bd922e6314edb7a710fdc0293265c2c42)
#1 0x5ee7c4d31d07 in std::pair<MMVII::eTySC const, std::__cxx11::basic_string<char, std::char_traits, std::allocator>>::pair<MMVII::eTySC, std::__cxx11::basic_string<char, std::char_traits, std::allocator> const&, true>(MMVII::eTySC&&, std::__cxx11::basic_string<char, std::char_traits, std::allocator> const&) /usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15/bits/stl_pair.h:902:35
#2 0x5ee7c4d31d07 in __cxx_global_var_init.37 /home/user/applications/MMVII/src/Serial/ElemStrToVal.cpp:213:28
#3 0x5ee7c4d31d07 in _GLOBAL__sub_I_ElemStrToVal.cpp /home/user/applications/MMVII/src/Serial/ElemStrToVal.cpp
#4 0x7ec54522a793 in call_init csu/../csu/libc-start.c:145:3
#5 0x7ec54522a793 in __libc_start_main csu/../csu/libc-start.c:347:5
#6 0x5ee7c4d56834 in _start (/home/user/applications/MMVII/bin/MMVII+0x64f834) (BuildId: 55945b601813b3db1fb38ef999fa38dda9333a6f)
==29477==Register values:
rax = 0x00007ac539503808 rbx = 0x00007ac5395037f8 rcx = 0x0000000000000000 rdx = 0x0000000000000001
rdi = 0x00007ac539503808 rsi = 0x0000000000000000 rbp = 0x00007ffc7ea83870 rsp = 0x00007ffc7ea83850
r8 = 0x0000000000000000 r9 = 0x00007c553a1eaf80 r10 = 0x00000f66a743d41d r11 = 0x0000000000000000
r12 = 0x00007ac5395037f0 r13 = 0x00007ac539503040 r14 = 0x00000f5927298000 r15 = 0x0000000000000000
`
Using some AI help, I came to the file:
MMVII/src/Serial/ElemStrToVal.cpp
where there is a default init of a string using a null ptr:
template<> cE2Str<eTySC>::tMapE2Str cE2Str<eTySC>::mE2S { {eTySC::NonInit,MMVII_NONE}, {eTySC::US,"unordered"}, };to be sure I replaced the NULL default by an empty string.
template<> cE2Str<eTySC>::tMapE2Str cE2Str<eTySC>::mE2S { {eTySC::NonInit,""}, {eTySC::US,"unordered"}, };Then it compiled successfully and at least it runs without the seg fault.
I have no idea of the deep implication of my change !
I haven't addressed the root cause. It was a quick and dirty fix to identify the problem.