Re: [Rd] Pressing either Ctrl-\ of Ctrl-4 core dumps R

[peter dalgaard]

On 12 Feb 2017, at 23:54 , Henrik Bengtsson  wrote:

> 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.

I would guess that this was just to get certain escape chars within reach on 
non-US keyboard layouts, e.g. the [\] characters are replaced by some 
permutation of the three extra letters in Scandinavian languages (as Henrik 
surely knows all about). So the awkward ones were reassigned/duplicated at 
Ctrl-2 -- Ctrl-8.

On, say, a current Mac Terminal.app, Ctrl-\ should be Ctrl-Shift-Alt-7, but 
that key combination actually just generates "7". I also recall terminals where 
some characters could only be obtained via compose sequences, e.g. compose-/-/ 
for "\", and there was no obvious way to add a Ctrl modifier to that.

-pd


-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Pressing either Ctrl-\ of Ctrl-4 core dumps R

[Henrik Bengtsson]

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 '.

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 = ; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; 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 .

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,   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 

Re: [Rd] Pressing either Ctrl-\ of Ctrl-4 core dumps R

[luke-tierney]

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 andFax:   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

[Rd] Pressing either Ctrl-\ of Ctrl-4 core dumps R

[Henrik Bengtsson]

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