Symptoms

The application crashes while opening a device within a thread of the Impact Acquire framework (e.g. mvGenTLProducer.cti). Analysis with a debugger shows that the crash occurs in a newly created thread immediately upon startup, during thread initialization.

Key characteristics:

• Simple demo programs (e.g., ContinuousCaptureAllDevices) run without issues
• The problem only manifests in complex applications that load many shared libraries
• At the moment of crash, the failing thread has just been created and other threads are in a waiting state

Cause

Some internal threads of Impact Acquire version 3.6.3 and earlier specify a stack size smaller than the default to save resources. While this stack size was sufficient in the past, it is inadequate on newer systems and larger applications for the following reasons:

• More recent versions of glibc on ARM64 require more space to manage SVE (Scalable Vector Extensions) registers
• When a new thread is created, the system must initialize TLS for all loaded libraries. This initialization process runs on the stack of the newly created thread
• The total static TLS requirement is the sum of all static TLS sections declared in all loaded libraries. Libraries like CUDA require very large static TLS allocations
• In complex applications with ~150 shared libraries, the TLS initialization exceeds stack size, causing an immediate stack overflow during thread startup
• Lightweight demo programs don't trigger this issue because they load only a few dependencies, and their combined TLS requirements fit on the stack

Resolution

Impact Acquire 3.7.0 and greater uses the default stack size of the operating system.

For legacy systems depending on the custom TLS behaviour it can be reactivated by setting the environment variable MVIMPACT_ACQUIRE_THREAD_STACK_SIZE_BEHAVIOUR to LEGACY.