On Sun, 3 Mar 2024 19:19:43 -0800 Kevin Ushey <kevinus...@gmail.com> wrote:
> Would libSegFault be useful here? Glad to know it has been moved to <https://github.com/zatrazz/glibc-tools/tree/main/libSegFault> and not just removed altogether after the upstream commit <https://sourceware.org/git/?p=glibc.git;a=commit;h=65ccd641bacea33be23d51da737c2de7543d0f5e>. libSegFault is safer than, say, libsegfault [*] because it both supports SA_ONSTACK (for when a SIGSEGV is caused by stack overflow) and avoids functions like snprintf() (which depend on the locale code, which may have been the source of the crash). The only correctness problem that may still be unaddressed is potential memory allocations in backtrace() when it loads libgcc on first use. That should be easy to fix by calling backtrace() once in segfault_init(). Unfortunately, libSegFault is limited to glibc systems, so a different solution will be needed on Windows, macOS and Linux systems with the musl libc. Google-owned "backward" [**] tries to do most of this right, but (1) is designed to be compiled together with C++ programs, not injected into unrelated processes and (2) will exit the process if it survives raise(signum), which will interfere with both rJava (judging by the number of Java-related SIGSEGVs I saw while running R CMD check) and R's own stack overflow survival attempts. -- Best regards, Ivan [*] https://github.com/stass/libsegfault (Which doesn't compile out of the box on GNU/Linux due to missing pthread_np.h, although that should be easy to patch.) [**] https://github.com/bombela/backward-cpp ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel