XLArig/5.2.3 gcc/10.2.1 segfault on start, rpi3b+ 1GB, raspios arm64 bullseye

[dermitza]

A bit of a strange issue. XLArig compiled fine and run fine with no issues for a few days. After a reboot and ever since, a segfault happens on start. The system or source files was not updated in between or changed in any way.

[2021-11-22 12:57:28.743]  cpu      use argon2 implementation default
[2021-11-22 12:57:29.944]  randomx  init dataset algo panthera (4 threads) seed 75eca4206d0e57d6...
[2021-11-22 12:57:29.944]  randomx  not enough memory for RandomX dataset
[2021-11-22 12:57:29.946]  randomx  failed to allocate RandomX dataset, switching to slow mode (2 ms)
Segmentation fault

Recompiling with debug symbols and a backtrace shows the following:

[2021-11-22 12:44:29.348]  randomx  not enough memory for RandomX dataset
[2021-11-22 12:44:29.349]  randomx  failed to allocate RandomX dataset, switching to slow mode (2 ms)
--Type <RET> for more, q to quit, c to continue without paging--

Thread 2 "xlarig" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff5565180 (LWP 1800)]
0x00000055559b5e00 in __aarch64_sync_cache_range ()
(gdb) backtrace
#0  0x00000055559b5e00 in __aarch64_sync_cache_range ()
#1  0x0000005555842160 in xmrig::VirtualMemory::flushInstructionCache (p=0x7ff0ca3498, size=23400)
    at /home/pi/XLArig/src/crypto/common/VirtualMemory_unix.cpp:194
#2  0x00000055558fcb78 in randomx::JitCompilerA64::generateSuperscalarHash<16ul> (this=0x7fe80197b0, programs=...)
    at /home/pi/XLArig/src/crypto/randomx/jit_compiler_a64.cpp:367
#3  0x00000055558cf33c in randomx::initCacheCompile (cache=0x7fe8001000, key=0x7fe80198b0, keySize=32)
    at /home/pi/XLArig/src/crypto/randomx/dataset.cpp:111
#4  0x00000055558d15cc in randomx_init_cache (cache=0x7fe8001000, key=0x7fe80198b0, keySize=32)
    at /home/pi/XLArig/src/crypto/randomx/randomx.cpp:445
#5  0x00000055558db9d0 in xmrig::RxCache::init (this=0x7fe8000d50, seed=std::vector of length 32, capacity 32 = {...})
    at /home/pi/XLArig/src/crypto/rx/RxCache.cpp:67
#6  0x00000055558dcf80 in xmrig::RxDataset::init (this=0x7fe8000c80, seed=std::vector of length 32, capacity 32 = {...}, numThreads=4, priority=-1)
    at /home/pi/XLArig/src/crypto/rx/RxDataset.cpp:96
#7  0x00000055558db314 in xmrig::RxBasicStoragePrivate::initDataset (this=0x5555b926f0, threads=4, priority=-1)
    at /home/pi/XLArig/src/crypto/rx/RxBasicStorage.cpp:86
#8  0x00000055558daed8 in xmrig::RxBasicStorage::init (this=0x5555b92550, seed=..., threads=4, hugePages=true, oneGbPages=false,
    mode=xmrig::RxConfig::AutoMode, priority=-1) at /home/pi/XLArig/src/crypto/rx/RxBasicStorage.cpp:174
#9  0x00000055558df3c8 in xmrig::RxQueue::backgroundInit (this=0x5555b90c90) at /home/pi/XLArig/src/crypto/rx/RxQueue.cpp:156
#10 0x00000055558e1738 in std::__invoke_impl<void, void (xmrig::RxQueue::*)(), xmrig::RxQueue*> (
    __f=@0x5555b91250: (void (xmrig::RxQueue::*)(xmrig::RxQueue * const)) 0x55558df234 <xmrig::RxQueue::backgroundInit()>,
    __t=@0x5555b91248: 0x5555b90c90) at /usr/include/c++/10/bits/invoke.h:73
#11 0x00000055558e164c in std::__invoke<void (xmrig::RxQueue::*)(), xmrig::RxQueue*> (
    __fn=@0x5555b91250: (void (xmrig::RxQueue::*)(xmrig::RxQueue * const)) 0x55558df234 <xmrig::RxQueue::backgroundInit()>)
    at /usr/include/c++/10/bits/invoke.h:95
#12 0x00000055558e15b0 in std::thread::_Invoker<std::tuple<void (xmrig::RxQueue::*)(), xmrig::RxQueue*> >::_M_invoke<0ul, 1ul> (this=0x5555b91248)
    at /usr/include/c++/10/thread:264
#13 0x00000055558e1568 in std::thread::_Invoker<std::tuple<void (xmrig::RxQueue::*)(), xmrig::RxQueue*> >::operator() (this=0x5555b91248)
    at /usr/include/c++/10/thread:271
#14 0x00000055558e1548 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (xmrig::RxQueue::*)(), xmrig::RxQueue*> > >::_M_run (
    this=0x5555b91240) at /usr/include/c++/10/thread:215
#15 0x000000555598f7bc in execute_native_thread_routine ()
#16 0x0000007ff7c1a628 in start_thread (arg=0x7ff5564a80) at pthread_create.c:477
#17 0x0000007ff7a6501c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

As this behaviour did not happen at the beginning for the first few program starts, and has since a day or so been consistently happening, I can only assume either (1) a recent different behaviour of the network resulting in possible thread race conditions or (2) deteriorated hardware due to the miner. (i.e. ram failure). Any suggestions?