R devel - Sep 2018 - Bug when calling system/system2 (and request for Bugzilla account)

Hi all,

I found some strange behaviour, which I think is a bug. Could someone make an
account for me on Bugzilla or pass on my report?

The problem:
When pressing Ctrl-C when a file is sourced in R, run from Terminal (macOS),
sometimes the entire session is ended right away, while I just want to stop the
script. This is the case when I press Ctrl-C while some functions are running
that don?t catch the interrupt. However, the behaviour is different whether I?m
in a clean session (in which case some time is allowed to pass, so that when the
function returns the script can be interrupted), or whether I have called
base::system() or system2() with timeout other than 0.

Reproducible example:
cat('Start non-interruptable functions\n')
sample_a <- sample(1:1e7)
sample_b <- sample(1:2e7)
matching <- match(sample_a, sample_b)
cat('Finished\n')
Sys.sleep(10)

Observed behaviour:
In a clean session, when I hit Ctrl-C during the execution of match, there is a
delay, and as soon as Sys.sleep() is invoked, the script is interrupted, I get
back my R ?>?-prompt (unless options(error=?) is set)
But If I add the line system2("ls", timeout = 5), or something
similar, when I try to break during the first part of the script, my Rsession
ends, I get thrown back to my terminal-prompt.

Desired behaviour:
The best setup would probably be if Ctrl-C would always try to break from the
sourced file, and only if that doesn?t success in n seconds, break the rsession
altogether, ideally with a customizable option. But maybe that?s too hard, so
maybe the most pragmatic would be to have 2 hotkeys: one to break from a
hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:

Expected behaviour:
Consistent behaviour for Ctrl-C: either trying to break the script, or end the
session altogether.

Some observations:

  *   I can still break cleanly during the Sys.sleep(). But for larger scripts,
it is largely a matter of luck if I hit Ctrl-C during the right moment.
  *   I don?t notice any difference between using system or system2, or any of
the arguments other than timeout provided
  *   I don?t notice any difference whether the timeout is actually exhausted or
not.
  *   Later calls to system/system2 don?t change anything (i.e. later calling
system(?, timeout=0) does not revert back to the old situation)

My setup:
R 3.5.1 (Feather Spray), run with ?vanilla option
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
macOS High Sierra 10.13.6

Best regards,
Emil Bode

Data-analyst

+31 6 43 83 89 33
emil.bode at dans.knaw.nl<mailto:emil.bode at dans.knaw.nl>

DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | info at
dans.knaw.nl<mailto:info at dans.kn> |
dans.knaw.nl<applewebdata://71F677F0-6872-45F3-A6C4-4972BF87185B/www.dans.knaw.nl>
DANS is an institute of the Dutch Academy KNAW<http://knaw.nl/nl> and
funding organisation NWO<http://www.nwo.nl/>.

	[[alternative HTML version deleted]]

I can't reproduce this. Can you be more precise: exactly where are you
putting the system2 call and exactly where are you sending the
interrupt signal with ^C?

Best,

luke

On Fri, 14 Sep 2018, Emil Bode wrote:
> Hi all,
>
> I found some strange behaviour, which I think is a bug. Could someone make
an account for me on Bugzilla or pass on my report?
>
> The problem:
> When pressing Ctrl-C when a file is sourced in R, run from Terminal
(macOS), sometimes the entire session is ended right away, while I just want to
stop the script. This is the case when I press Ctrl-C while some functions are
running that don?t catch the interrupt. However, the behaviour is different
whether I?m in a clean session (in which case some time is allowed to pass, so
that when the function returns the script can be interrupted), or whether I have
called base::system() or system2() with timeout other than 0.
>
> Reproducible example:
> cat('Start non-interruptable functions\n')
> sample_a <- sample(1:1e7)
> sample_b <- sample(1:2e7)
> matching <- match(sample_a, sample_b)
> cat('Finished\n')
> Sys.sleep(10)
>
> Observed behaviour:
> In a clean session, when I hit Ctrl-C during the execution of match, there
is a delay, and as soon as Sys.sleep() is invoked, the script is interrupted, I
get back my R ?>?-prompt (unless options(error=?) is set)
> But If I add the line system2("ls", timeout = 5), or something
similar, when I try to break during the first part of the script, my Rsession
ends, I get thrown back to my terminal-prompt.
>
> Desired behaviour:
> The best setup would probably be if Ctrl-C would always try to break from
the sourced file, and only if that doesn?t success in n seconds, break the
rsession altogether, ideally with a customizable option. But maybe that?s too
hard, so maybe the most pragmatic would be to have 2 hotkeys: one to break from
a hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:
>
> Expected behaviour:
> Consistent behaviour for Ctrl-C: either trying to break the script, or end
the session altogether.
>
> Some observations:
>
>  *   I can still break cleanly during the Sys.sleep(). But for larger
scripts, it is largely a matter of luck if I hit Ctrl-C during the right moment.
>  *   I don?t notice any difference between using system or system2, or any
of the arguments other than timeout provided
>  *   I don?t notice any difference whether the timeout is actually
exhausted or not.
>  *   Later calls to system/system2 don?t change anything (i.e. later
calling system(?, timeout=0) does not revert back to the old situation)
>
> My setup:
> R 3.5.1 (Feather Spray), run with ?vanilla option
> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
> macOS High Sierra 10.13.6
>
> Best regards,
> Emil Bode
>
> Data-analyst
>
> +31 6 43 83 89 33
> emil.bode at dans.knaw.nl<mailto:emil.bode at dans.knaw.nl>
>
> DANS: Netherlands Institute for Permanent Access to Digital Research
Resources
> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | info at
dans.knaw.nl<mailto:info at dans.kn> |
dans.knaw.nl<applewebdata://71F677F0-6872-45F3-A6C4-4972BF87185B/www.dans.knaw.nl>
> DANS is an institute of the Dutch Academy KNAW<http://knaw.nl/nl> and
funding organisation NWO<http://www.nwo.nl/>.
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at 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-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

I hope it's not too specific in my setup...
I've tried with system2 added on the first line, so:

Example.R:
system2('ls', timeout=5)
cat('Start non-interruptable functions\n')
sample_a <- sample(1:1e7)
sample_b <- sample(1:2e7)
matching <- match(sample_a, sample_b)
cat('Finished\n')
Sys.sleep(10)

And in terminal/bash:
R --vanilla
source('Example.R')
Send ^C between the messages (Start...  until Finished)

Or if you have a more powerful CPU you can increase the samples, the exact code
doesn't matter very much.
As soon as you restart and source again with the system2 call outcommented, the
behaviour is different, there is a pause, and your return to the R-prompt.

Best, Emil



?On 14/09/2018, 17:39, "luke-tierney at uiowa.edu" <luke-tierney at
uiowa.edu> wrote:

    I can't reproduce this. Can you be more precise: exactly where are you
    putting the system2 call and exactly where are you sending the
    interrupt signal with ^C?
    
    Best,
    
    luke
    
    On Fri, 14 Sep 2018, Emil Bode wrote:
    
    > Hi all,
    >
    > I found some strange behaviour, which I think is a bug. Could someone
make an account for me on Bugzilla or pass on my report?
    >
    > The problem:
    > When pressing Ctrl-C when a file is sourced in R, run from Terminal
(macOS), sometimes the entire session is ended right away, while I just want to
stop the script. This is the case when I press Ctrl-C while some functions are
running that don?t catch the interrupt. However, the behaviour is different
whether I?m in a clean session (in which case some time is allowed to pass, so
that when the function returns the script can be interrupted), or whether I have
called base::system() or system2() with timeout other than 0.
    >
    > Reproducible example:
    > cat('Start non-interruptable functions\n')
    > sample_a <- sample(1:1e7)
    > sample_b <- sample(1:2e7)
    > matching <- match(sample_a, sample_b)
    > cat('Finished\n')
    > Sys.sleep(10)
    >
    > Observed behaviour:
    > In a clean session, when I hit Ctrl-C during the execution of match,
there is a delay, and as soon as Sys.sleep() is invoked, the script is
interrupted, I get back my R ?>?-prompt (unless options(error=?) is set)
    > But If I add the line system2("ls", timeout = 5), or
something similar, when I try to break during the first part of the script, my
Rsession ends, I get thrown back to my terminal-prompt.
    >
    > Desired behaviour:
    > The best setup would probably be if Ctrl-C would always try to break
from the sourced file, and only if that doesn?t success in n seconds, break the
rsession altogether, ideally with a customizable option. But maybe that?s too
hard, so maybe the most pragmatic would be to have 2 hotkeys: one to break from
a hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:
    >
    > Expected behaviour:
    > Consistent behaviour for Ctrl-C: either trying to break the script, or
end the session altogether.
    >
    > Some observations:
    >
    >  *   I can still break cleanly during the Sys.sleep(). But for larger
scripts, it is largely a matter of luck if I hit Ctrl-C during the right moment.
    >  *   I don?t notice any difference between using system or system2, or
any of the arguments other than timeout provided
    >  *   I don?t notice any difference whether the timeout is actually
exhausted or not.
    >  *   Later calls to system/system2 don?t change anything (i.e. later
calling system(?, timeout=0) does not revert back to the old situation)
    >
    > My setup:
    > R 3.5.1 (Feather Spray), run with ?vanilla option
    > GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
    > macOS High Sierra 10.13.6
    >
    > Best regards,
    > Emil Bode
    >
    > Data-analyst
    >
    > +31 6 43 83 89 33
    > emil.bode at dans.knaw.nl<mailto:emil.bode at dans.knaw.nl>
    >
    > DANS: Netherlands Institute for Permanent Access to Digital Research
Resources
    > Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | info at
dans.knaw.nl<mailto:info at dans.kn> |
dans.knaw.nl<applewebdata://71F677F0-6872-45F3-A6C4-4972BF87185B/www.dans.knaw.nl>
    > DANS is an institute of the Dutch Academy KNAW<http://knaw.nl/nl>
and funding organisation NWO<http://www.nwo.nl/>.
    >
    > 	[[alternative HTML version deleted]]
    >
    > ______________________________________________
    > R-devel at 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-tierney at uiowa.edu
    Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

>>>>> Emil Bode    on Fri, 14 Sep 2018 13:04:29 +0000 writes:
    > I found some strange behaviour, which I think is a bug. 
    > Could someone make an account for me on Bugzilla or
    > pass on my report?

I did create a bugzilla account for you (you should've got the
automatic e-mail in the mean time)...
but *DO* (all readers!) still keep in mind what we wrote carefully in

    https://www.r-project.org/bugs.html

In particular:

   Not everything that surprises you in R is a bug.
   Rather carefully read the official documentation (the help
   page at a minimum) of a function before claiming a bug. 

I've been a bit appalled about the amount of recent e-mails on
R-devel of people not having looked at the reference
documentation and claiming things...

  [......omitted..........]
  [......omitted..........]

and you did note and report a real bug indeed,
thank you !!

Martin