dd-cxx: address sanitizer segfault

[justadreamer]

Background

There are intermittent failures of EngineHashTestsFileLowMemoryNull tests when running with AddressSanitizer instrumentation. Usually it is MultiThreadRandom but sometimes other tests f.e.:
https://github.com/51Degrees/device-detection-cxx/actions/runs/12689965609/job/35369851890#step:5:1693

  [ RUN      ] EngineHashTestsFileLowMemoryNull.MultiThreadRandom
  AddressSanitizer:DEADLYSIGNAL
  =================================================================
  ==5984==ERROR: AddressSanitizer: SEGV on unknown address 0x5140002d0000 (pc 0x5555557b94f0 bp 0x7ffff29ff800 sp 0x7ffff29ff670 T2)
  ==5984==The signal is caused by a READ memory access.
      #0 0x5555557b94f0 in fiftyoneDegreesProfileIterateValuesForProperty (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x2654f0) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #1 0x5555557a8851 in fiftyoneDegreesResultsHashGetValues (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x254851) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #2 0x555555764338 in FiftyoneDegrees::DeviceDetection::Hash::ResultsHash::getValuesInternal(int, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x210338) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #3 0x5555557b11bc in FiftyoneDegrees::Common::ResultsBase::getValues[abi:cxx11](int) (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x25d1bc) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #4 0x55555575530e in EngineTests::validateQuick(FiftyoneDegrees::Common::ResultsBase*) (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x20130e) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #5 0x55555574c0e9 in EngineDeviceDetectionTests::randomWithEvidence(int) (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x1f80e9) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #6 0x555555746236 in EngineDeviceDetectionTests::multiThreadRandomRunThread(void*) (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x1f2236) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
      #7 0x7ffff785ea41 in asan_thread_start ../../../../src/libsanitizer/asan/asan_interceptors.cpp:234
      #8 0x7ffff709ca93  (/lib/x86_64-linux-gnu/libc.so.6+0x9ca93) (BuildId: 6d64b17fbac799e68da7ebd9985ddf9b5cb375e6)
      #9 0x7ffff7129c3b  (/lib/x86_64-linux-gnu/libc.so.6+0x129c3b) (BuildId: 6d64b17fbac799e68da7ebd9985ddf9b5cb375e6)
  
  AddressSanitizer can not provide additional info.
  SUMMARY: AddressSanitizer: SEGV (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x2654f0) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8) in fiftyoneDegreesProfileIterateValuesForProperty
  Thread T2 created by T0 here:
      #0 0x7ffff78f51f9 in pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:245
      #1 0x5555557533cf in Base::runThreads(int, void* (*)(void*)) (/home/runner/work/device-detection-cxx/device-detection-cxx/common/device-detection-cxx/build/bin/HashTests+0x1ff3cf) (BuildId: 2679b4c3429d624ee4499d8029b94013a1eafed8)
  
  ==5984==ABORTING

Objective

Find out the root cause and eliminate it.

[justadreamer]

There are also Data Races discovered by Thread Sanitizer in the same test conditions but within pool.c - dealing with file handle pool races. However pool.c is built as a lock-free stack data structure following this article https://nullprogram.com/blog/2014/09/02/ The example from within that article https://github.com/skeeto/lstack - also does not pass Thread Sanitizer - there are races detected in it. Which kinda leads to 2 thoughts:

• either there are indeed races
• or these are false alarms because lock-free data structures trick Thread Sanitizer

In the former case Address Sanitizer failures could be a consequence of Data Races, while in the latter case these are separate issues.