interrupting devtools::test() leaves behind recursively-faulting R processes #1819
Comments
|
One workaround is to set: so that R doesn't try to install its SEGV handlers. |
|
I filed a bug report for R as well; I believe R should be unsetting the SEGV handler while processing the signal. https://bugs.r-project.org/show_bug.cgi?id=18551 |
|
Seems like |
|
Btw. I also don't really understand why the subprocesses of the test process get SEGV signals. |
|
Here's a traceback I was able to capture: |
|
Thanks! Is this the test process or a subprocess of the test process? |
|
Other traces look different, but one common thing I'm noticing is that R is being run on multiple threads... It seems like the SEGV handler isn't actually being run on the main R thread? So the processx bit might be a red herring; it's more that we have multiple threads and the signal handler isn't being assigned to the main thread for some reason? |
|
I'm just here to say that I experienced something that presented exactly like this:
while running testthat's tests (by mistake), then interrupting them. |
gaborcsardi
added a commit
to r-lib/processx
that referenced
this issue
Jun 17, 2023
Otherwise a SIGPIPE may freeze an R process, like we saw in parallel testthat tests: r-lib/testthat#1819 Here the main proces is killed, but the worker processes are not, and when a worker process tries to send the test results to the main process, a `write()` on its pipe gets a `SIGPIPE. Unclear why, but the `SIGPIPE` sometimes causes a `SIGSEGV`, for which R tries to print the stack, but gets another `SIGSEGV`, and so on.
|
This is now fixed in processx with r-lib/processx@da4cf5a I'll make a processx release sure, after which testthat could depend on the new processx version. Until then, you can use the |
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this issue
Aug 15, 2023
# processx 3.8.2 * The client library, used by callr, now ignores `SIGPIPE` when writing to a file descriptor, on unix. This avoid possible freezes when a `callr::r_session` subprocess is trying to report its result after the main process was terminated. In particular, this happened with parallel testthat: r-lib/testthat#1819
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To reproduce, in RStudio:
The running R process receives a SIGTERM and exits, but the sub-processes are left behind.
At least on macOS, those processes get stuck in an infinite busy loop, chewing up lots of CPU. lldb reports:
so it seems like the R processes are getting stuck recursively handling SIGSEGV errors.
The text was updated successfully, but these errors were encountered: