Currently segmentation faults or core dumps do not result in a stacktrace. This is problematic when debugging issues, such as #29889 (comment)
Fix it by running everything in Nulgrind, which has less overhead than Valgrind, unless Valgrind is already selected.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For detailed information about the code coverage, see the test coverage report.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process. A summary of reviews will appear here.
I looked into many alternatives, such as gdb --batch --ex ..., or catchsegv, but none of them worked in the CI setting.
I think the only reasonable alternative would be to implement a signal handler in the C++ code.
Another alternative would be to wait for C++ (or compilers) to port RUST_BACKTRACE, but that seems unlikely, or at least far out in the feature.
11 | @@ -12,7 +12,11 @@ for b_name in "${BASE_OUTDIR}/bin"/*; do 12 | echo "Wrap $b ..." 13 | mv "$b" "${b}_orig" 14 | echo '#!/usr/bin/env bash' > "$b" 15 | - echo "valgrind --gen-suppressions=all --quiet --error-exitcode=1 --suppressions=${BASE_ROOT_DIR}/contrib/valgrind.supp \"${b}_orig\" \"\$@\"" >> "$b" 16 | + if [ -n "$USE_VALGRIND" ]; then
Not sure I fully understand the consequences here, but do we want to replace the files with empty ones when USE_VALGRIND is false?
Shouldn't we execute the old ones in that case?
I guess this is too fragile to be useful