Thanks for these explanations - it all makes sense, that is, the default behavior for a process that does not capture SIGQUIT is to quit and perform a core dump (https://en.wikipedia.org/wiki/Unix_signal#SIGQUIT).
Then the remaining question, as Luke says, is: should R handle this signal? For instance, in interactive mode, SIGQUIT could maybe bring up: Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace 5: ignore SIGQUIT (continue evaluation) Selection: giving the option to ignore a SIGQUIT send by mistake. Not sure how big of a problem this is (I'm surprise I never hit Ctrl+\ by mistake previously). Also, I'm sharing my notes about stty and SIGQUIT in case someone else finds them useful: My terminal (Linux / Ubuntu 16.04) settings are the same as Bill's (stty --all). Thus, pressing Ctrl+\ causes the terminal to signals SIGQUIT to the running process (= R). Since R does not handle / capture this specifically, this results in the process to quit and perform a core dump. Pressing Ctrl+\ is effectively the same a calling 'kill -s QUIT <pid>'. One can disable the QUIT signal send by the terminal by: $ stty quit '' such that one gets: $ stty --all speed 38400 baud; rows 33; columns 80; line = 0; intr = ^C; quit = <undef>; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc This will prevent QUIT to be signalled when pressing Ctrl+\ and thereby R (Python, ...) won't core dump. One can of course still use kill -s QUIT <pid>. To reset the above, either restart the terminal or use either of: $ stty quit ^\\ ## caret notation (espaced ^\) $ stty quit 0x1c ## hexadecimal notation $ stty quit 034 ## octal notation $ stty quit 28 ## decimal notation I still don't understand why the terminal treats keypress Ctrl+4 the same as Ctrl+\, but at least I'm not alone; https://catern.com/posts/terminal_quirks.html#fn.3. Thanks Henrik On Fri, Feb 10, 2017 at 11:00 AM, <luke-tier...@uiowa.edu> wrote: > So do a number of other interactive programs when working in a > terminal (e.g. python) since it looks like your terminal is configured > for those two actions to send the SIGQUIT signal. Whether R should > ignore that signal, under some circumstances at least, is another > question. > > Best, > > luke > > > On Fri, 10 Feb 2017, Henrik Bengtsson wrote: > >> When running R from the terminal on Linux (Ubuntu 16.04), it core >> dumps whenever / wherever I press Ctrl-4 or Ctrl-\. You get thrown >> back to the terminal with "Quit (core dump)" being the only message. >> Grepping the R source code, it doesn't look like that message is >> generated by R itself. Over on Twitter, it has been confirmed to also >> happen on macOS. >> >> $ R -d valgrind --vanilla --quiet >> ==979== Memcheck, a memory error detector >> ==979== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. >> ==979== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info >> ==979== Command: /usr/lib/R/bin/exec/R --vanilla --quiet >> ==979== >>> >>> 1+2 >> >> [1] 3 >> >> # At next prompt I press Ctrl-\. The same happens also when done in >> the middle of an entry. >> >>> ==979== >> >> ==979== Process terminating with default action of signal 3 (SIGQUIT) >> ==979== at 0x576C9C3: __select_nocancel (syscall-template.S:84) >> ==979== by 0x502EABE: R_SelectEx (in /usr/lib/R/lib/libR.so) >> ==979== by 0x502EDDF: R_checkActivityEx (in /usr/lib/R/lib/libR.so) >> ==979== by 0x502F32B: ??? (in /usr/lib/R/lib/libR.so) >> ==979== by 0x4F6988B: Rf_ReplIteration (in /usr/lib/R/lib/libR.so) >> ==979== by 0x4F69CF0: ??? (in /usr/lib/R/lib/libR.so) >> ==979== by 0x4F69DA7: run_Rmainloop (in /usr/lib/R/lib/libR.so) >> ==979== by 0x4007CA: main (in /usr/lib/R/bin/exec/R) >> ==979== >> ==979== HEAP SUMMARY: >> ==979== in use at exit: 28,981,596 bytes in 13,313 blocks >> ==979== total heap usage: 27,002 allocs, 13,689 frees, 49,025,684 >> bytes allocated >> ==979== >> ==979== LEAK SUMMARY: >> ==979== definitely lost: 0 bytes in 0 blocks >> ==979== indirectly lost: 0 bytes in 0 blocks >> ==979== possibly lost: 0 bytes in 0 blocks >> ==979== still reachable: 28,981,596 bytes in 13,313 blocks >> ==979== suppressed: 0 bytes in 0 blocks >> ==979== Rerun with --leak-check=full to see details of leaked memory >> ==979== >> ==979== For counts of detected and suppressed errors, rerun with: -v >> ==979== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) >> Quit (core dumped) >> >> $ R --version >> R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch" >> Copyright (C) 2016 The R Foundation for Statistical Computing >> Platform: x86_64-pc-linux-gnu (64-bit) >> >> /Henrik >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics and Fax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel