It may be that the error is sufficiently bad that the stack trace has disappeared by the time the signal handler is called but often it is useful (i.e. better than nothing) in that it reports the stack is empty.
Valgrind valgrind-3.15.0 does not support Intel AVX512 vector instructions.
Valgrind with non-AVX version of code finds a few initialised
variables but nothing the explains late crash.
Long run time makes interactive GDB hopeless
A better approach may be, if you have the source code, to add a signal handler for signal SIGSEGV see example segv.c
fails to detach from the interactive terminal and run independently in the background. Instead it produces Suspended (tty output)
script.bat contains tcsh command including GDB commands to run in batch mode (-batch), run the program and generate a back track stack dump (bt) when the program fails. Fragment:
#WBL 8 Nov 2020 gdb -batch -return-child-result \ --eval-command=run --eval-command=bt --args \ ./program \ program's arguments setenv save $status if($save) then echo "gdb ... ./program failed status $save" exit $save endif echo "$0 done status $save" `date` exit $save
It appears that despite the -batch argument, GDB is trying to read user commands from the terminal.
./script.bat < /dev/null >& script.out &
Although program is multi-threaded, it appears that the GDB overhead is high and the multiple CPUs are not effectively used.