[Rd] Background R session on Unix and SIGINT
Hi All, I realize that this is not a really nice reprex, but anyone has an idea why a background R session would "remember" an interrupt (SIGINT) on Unix? rs <- callr::r_session$new() rs$interrupt() # just sends a SIGINT #> [1] TRUE rs$run(function() 1+1) #> Error: interrupt rs$run(function() 1+1) #> [1] 2 It seems that the main loop somehow stores the SIGINT it receives while it is waiting on stdin, and then it triggers it when some input comes in Maybe. Just speculating Thanks, Gabor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Background R session on Unix and SIGINT
Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. Cheers, Simon > On Apr 30, 2019, at 3:44 PM, Gábor Csárdi wrote: > > Hi All, > > I realize that this is not a really nice reprex, but anyone has an > idea why a background R session would "remember" an interrupt (SIGINT) > on Unix? > > rs <- callr::r_session$new() > rs$interrupt() # just sends a SIGINT > #> [1] TRUE > > rs$run(function() 1+1) > #> Error: interrupt > > rs$run(function() 1+1) > #> [1] 2 > > It seems that the main loop somehow stores the SIGINT it receives > while it is waiting on stdin, and then it triggers it when some input > comes in Maybe. Just speculating > > Thanks, > Gabor > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Background R session on Unix and SIGINT
Yeah, I get that they are async. What happens is that the background process is not doing anything when the process gets a SIGINT. I.e. the background process is just listening on its standard input. AFAICT for an interactive process such a SIGINT is just swallowed, with a newline outputted to the terminal. But apparently, for this background process, it is not swallowed, and it is triggered later. FWIW it does not happen on Windows, not very surprisingly. Gabor On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek wrote: > > Interrupts are not synchronous in R - the signal only flags the request for > interruption. Nothing actually happens until R_CheckUserInterrupt() is called > at an interruptible point. In you case your code is apparently not calling > R_CheckUserInterrupt() until later as a side-effect of the next evaluation. > > Cheers, > Simon > > > > On Apr 30, 2019, at 3:44 PM, Gábor Csárdi wrote: > > > > Hi All, > > > > I realize that this is not a really nice reprex, but anyone has an > > idea why a background R session would "remember" an interrupt (SIGINT) > > on Unix? > > > > rs <- callr::r_session$new() > > rs$interrupt() # just sends a SIGINT > > #> [1] TRUE > > > > rs$run(function() 1+1) > > #> Error: interrupt > > > > rs$run(function() 1+1) > > #> [1] 2 > > > > It seems that the main loop somehow stores the SIGINT it receives > > while it is waiting on stdin, and then it triggers it when some input > > comes in Maybe. Just speculating > > > > Thanks, > > Gabor > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Background R session on Unix and SIGINT
Can you give an example without callr? The key is how is the process stated and what it is doing which is entirely opaque in callr. Windows doesn't have signals, so the process there is entirely different. Most of the WIN32 processing is event-based. Cheers, Simon > On Apr 30, 2019, at 4:17 PM, Gábor Csárdi wrote: > > Yeah, I get that they are async. > > What happens is that the background process is not doing anything when > the process gets a SIGINT. I.e. the background process is just > listening on its standard input. > > AFAICT for an interactive process such a SIGINT is just swallowed, > with a newline outputted to the terminal. > > But apparently, for this background process, it is not swallowed, and > it is triggered later. FWIW it does not happen on Windows, not very > surprisingly. > > Gabor > > On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > wrote: >> >> Interrupts are not synchronous in R - the signal only flags the request for >> interruption. Nothing actually happens until R_CheckUserInterrupt() is >> called at an interruptible point. In you case your code is apparently not >> calling R_CheckUserInterrupt() until later as a side-effect of the next >> evaluation. >> >> Cheers, >> Simon >> >> >>> On Apr 30, 2019, at 3:44 PM, Gábor Csárdi wrote: >>> >>> Hi All, >>> >>> I realize that this is not a really nice reprex, but anyone has an >>> idea why a background R session would "remember" an interrupt (SIGINT) >>> on Unix? >>> >>> rs <- callr::r_session$new() >>> rs$interrupt() # just sends a SIGINT >>> #> [1] TRUE >>> >>> rs$run(function() 1+1) >>> #> Error: interrupt >>> >>> rs$run(function() 1+1) >>> #> [1] 2 >>> >>> It seems that the main loop somehow stores the SIGINT it receives >>> while it is waiting on stdin, and then it triggers it when some input >>> comes in Maybe. Just speculating >>> >>> Thanks, >>> Gabor >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
Hi Peter
Yes, that looks roughly right to me. I would be in favour of your
option (b), partly because it is probably easiest and partly because
that retains the basic graphics device startup logic pattern that is
replicated across all(?) graphics devices.
Paul
On 28/04/19 11:39 AM, peter dalgaard wrote:
I had a look at the current code, and AFAICT it has essentially the same
structure as it did back then. I think it may have finally dawned upon me what
the issue really is:
The logic is that in Rf_addX11Device, we have
if (!X11DeviceDriver(dev, display, width, height,
ps, gamma, colormodel, maxcubesize,
bgcolor, canvascolor, sfonts, res,
xpos, ypos, title, useCairo, antialias, family)) {
free(dev);
errorcall(call, _("unable to start device %s"), devname);
}
dd = GEcreateDevDesc(dev);
GEaddDevice2(dd, devname);
i.e., we start the device driver, and if it fails, we throw away the "dev"
structure and call it a day. If it succeeds, we proceed to create a device descriptor
structure and add it to the list of open devices.
This approach means that X11DeviceDriver() cannot do anything that potentially
accesses the dd structure because it isn't there yet, and the things it cannot
do apparently includes calling R_ProcessX11Events(). [To be completely sure
that this is actually still true, I'd need to have a closer look at what
handleEvent() does.]
So to fix things, it would seem that you could (a) add the device before
attempting to start the driver, preparing to back it out if the driver fails to
start, or (b) add a call to R_ProcessX11Events() _after_ the GEaddDevice2(dd,
devname). Option (b) is probably the easiest.
Paul: Does this analysis look roughly right?
-pd
On 26 Apr 2019, at 01:23 , frede...@ofb.net wrote:
Thanks Professor Dalgard.
If you have a different way to fix the bug then I'd be happy to test
it.
Or whatever. I understand that maybe some data was being referenced
before it had been initialized. I could also support moving the
R_ProcessEvents call in another place, but it seems one would also
like to generate some kind of warning message, at the location of the
bad reference, rather than segfaulting. Was it not possible to
identify this location? I'm guessing that Valgrind is a bit more
mature now than it was in 2001...?
Frederick
On Wed, Apr 24, 2019 at 03:12:55PM +0200, peter dalgaard wrote:
OK, so I did the archaeology anyway
This was the story, R-core November 29, 2001. Part of thread "X11 still
segfaults".
>>
.
Gah. I've been too tired today. Why did that take me so long?
The culprit seems to be
R_ProcessEvents((void*) NULL)
in newX11DeviceDriver
This gets called *before* this stuff at the end of Rf_addX11Device
dd = GEcreateDevDesc(dev);
addDevice((DevDesc*) dd);
initDisplayList((DevDesc*) dd);
and it is that "dd" that gets called by Rf_playDisplayList. Removing
the offending line stops the segfaulting, seemingly with no ill
effects.
I'm not really sure what the use of that line ever was; it might be
necessary to make the call somewhere later, but it appears to have
been possible to race past it before receiving any events all the
time.
I also changed a couple of spots missing dd->newDevStruct=1
Will commit in a moment.
<<
And the following day, in "graphics saga part III", we had
->>
...
I can't make it happen in 1.3.1 but...
It is probably not unrelated to the R_ProcessEvents line that
I took out, but that was definitely wrong. However, one might reenable
it if one could change this bit of code
if (!(ptr_X11DeviceDriver)((DevDesc*)(dev), display, width, height, ps,
gamma,
colormodel, maxcubesize, canvascolor)) {
free(dev);
errorcall(gcall, "unable to start device %s", devname);
}
gsetVar(install(".Device"), mkString(devname), R_NilValue);
dd = GEcreateDevDesc(dev);
addDevice((DevDesc*) dd);
initDisplayList((DevDesc*) dd);
and put the if-clause last. A cursory clance through the three
functions that are being called didn't reveal anything that would rely
on having opened the device driver first.
Paul?
(I might try it locally, but I'm not sure I should commit anything.)
<<---
It seems that the suggestion was never followed up on?
-pd
On 24 Apr 2019, at 11:42 , peter dalgaard wrote:
I don't recall exactly what I did 18 years ago eiher and I likely don't have
the time to dig into the archives and reconstruct.
I can imagine that the issue had to do with the protocol around creating and
mapping windows. Presumably the segfault comes from looking for events on a
window that hasn't been created yet, or has already been destroyed, leading to
a NULL reference somewhere. I have a vague recollectio
Re: [Rd] Background R session on Unix and SIGINT
OK, I managed to create an example without callr, but it is still somewhat cumbersome. Anyway, here it is. Terminal 1: mkfifo fif R --no-readline --slave --no-save --no-restore < fif Terminal 2: cat > fif Sys.getpid() This will make Terminal 1 print the pid of the R process, so we can send a SIGINT: Terminal 3: kill -INT pid The R process is of course still running happily. Terminal 2 again: tryCatch(Sys.sleep(10), interrupt = function(e) e) and then Terminal 1 prints the interrupt condition: This is macOS and 3.5.3, although I don't think it matters much. Thanks much! G. On Tue, Apr 30, 2019 at 9:50 PM Simon Urbanek wrote: > > Can you give an example without callr? The key is how is the process stated > and what it is doing which is entirely opaque in callr. > > Windows doesn't have signals, so the process there is entirely different. > Most of the WIN32 processing is event-based. > > Cheers, > Simon > > > > On Apr 30, 2019, at 4:17 PM, Gábor Csárdi wrote: > > > > Yeah, I get that they are async. > > > > What happens is that the background process is not doing anything when > > the process gets a SIGINT. I.e. the background process is just > > listening on its standard input. > > > > AFAICT for an interactive process such a SIGINT is just swallowed, > > with a newline outputted to the terminal. > > > > But apparently, for this background process, it is not swallowed, and > > it is triggered later. FWIW it does not happen on Windows, not very > > surprisingly. > > > > Gabor > > > > On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > > wrote: > >> > >> Interrupts are not synchronous in R - the signal only flags the request > >> for interruption. Nothing actually happens until R_CheckUserInterrupt() is > >> called at an interruptible point. In you case your code is apparently not > >> calling R_CheckUserInterrupt() until later as a side-effect of the next > >> evaluation. > >> > >> Cheers, > >> Simon > >> > >> > >>> On Apr 30, 2019, at 3:44 PM, Gábor Csárdi wrote: > >>> > >>> Hi All, > >>> > >>> I realize that this is not a really nice reprex, but anyone has an > >>> idea why a background R session would "remember" an interrupt (SIGINT) > >>> on Unix? > >>> > >>> rs <- callr::r_session$new() > >>> rs$interrupt() # just sends a SIGINT > >>> #> [1] TRUE > >>> > >>> rs$run(function() 1+1) > >>> #> Error: interrupt > >>> > >>> rs$run(function() 1+1) > >>> #> [1] 2 > >>> > >>> It seems that the main loop somehow stores the SIGINT it receives > >>> while it is waiting on stdin, and then it triggers it when some input > >>> comes in Maybe. Just speculating > >>> > >>> Thanks, > >>> Gabor > >>> > >>> __ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: Background R session on Unix and SIGINT
A Simon pointed out the interrupt is recorded but not processed until a safe point. When reading from a fifo or pipe R runs non-interactive, which means is sits in a read() system call and the interrupt isn't seen until sometime during evaluation when a safe checkpoint is reached. When reading from a terminal R will use select() to wait for input and periodically wake and check for interrupts. In that case the interrupt will probably be seen sooner. If the interactive behavior is what you want you can add --interactive to the arguments used to start R. Best, luke On Tue, 30 Apr 2019, Gábor Csárdi wrote: > OK, I managed to create an example without callr, but it is still > somewhat cumbersome. Anyway, here it is. > > Terminal 1: > mkfifo fif > R --no-readline --slave --no-save --no-restore < fif > > Terminal 2: > cat > fif > Sys.getpid() > > This will make Terminal 1 print the pid of the R process, so we can > send a SIGINT: > > Terminal 3: > kill -INT pid > > The R process is of course still running happily. > > Terminal 2 again: > tryCatch(Sys.sleep(10), interrupt = function(e) e) > > and then Terminal 1 prints the interrupt condition: > > > This is macOS and 3.5.3, although I don't think it matters much. > > Thanks much! > G. > > On Tue, Apr 30, 2019 at 9:50 PM Simon Urbanek > wrote: >> >> Can you give an example without callr? The key is how is the process stated >> and what it is doing which is entirely opaque in callr. >> >> Windows doesn't have signals, so the process there is entirely different. >> Most of the WIN32 processing is event-based. >> >> Cheers, >> Simon >> >> >>> On Apr 30, 2019, at 4:17 PM, Gábor Csárdi wrote: >>> >>> Yeah, I get that they are async. >>> >>> What happens is that the background process is not doing anything when >>> the process gets a SIGINT. I.e. the background process is just >>> listening on its standard input. >>> >>> AFAICT for an interactive process such a SIGINT is just swallowed, >>> with a newline outputted to the terminal. >>> >>> But apparently, for this background process, it is not swallowed, and >>> it is triggered later. FWIW it does not happen on Windows, not very >>> surprisingly. >>> >>> Gabor >>> >>> On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek >>> wrote: Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. Cheers, Simon > On Apr 30, 2019, at 3:44 PM, Gábor Csárdi wrote: > > Hi All, > > I realize that this is not a really nice reprex, but anyone has an > idea why a background R session would "remember" an interrupt (SIGINT) > on Unix? > > rs <- callr::r_session$new() > rs$interrupt() # just sends a SIGINT > #> [1] TRUE > > rs$run(function() 1+1) > #> Error: interrupt > > rs$run(function() 1+1) > #> [1] 2 > > It seems that the main loop somehow stores the SIGINT it receives > while it is waiting on stdin, and then it triggers it when some input > comes in Maybe. Just speculating > > Thanks, > Gabor > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > >>> >> > > __ > 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] mccollect with NULL in R 3.6
Dear All, I'm running into issues with calling mccollect on a list containing NULL using R 3.6 (this used to work in 3.5.3): jobs <- lapply( list(NULL, 'foobar'), function(x) mcparallel(identity(x))) mccollect(jobs, wait = FALSE, timeout = 0) #> Error in names(res) <- pnames[match(s, pids)] : #> 'names' attribute [2] must be the same length as the vector [1] Note, setting a "name" for the jobs does not help, but the above works with "wait=TRUE", and also if I change the order of NULL and "foobar", although in that case, the second value (NULL) is ommitted. It also works with mclapply fine. Any ideas/suggestion on how to get mccollect work with the above example? Thanks, Gergely [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: Background R session on Unix and SIGINT
Unfortunately --interactive also makes the session interactive(), which is bad for me, as it is a background session. In general, I don't want the interactive behavior, but was wondering if I could send as SIGINT to try to interrupt the computation of the background process, and if that does not work, then I would send a SIGKILL and start up another process. It all works nicely, except for this glitch, but I think I can work around it. Thanks, Gabor On Tue, Apr 30, 2019 at 10:55 PM Tierney, Luke wrote: > > A Simon pointed out the interrupt is recorded but not processed until > a safe point. > > When reading from a fifo or pipe R runs non-interactive, which means > is sits in a read() system call and the interrupt isn't seen until > sometime during evaluation when a safe checkpoint is reached. > > When reading from a terminal R will use select() to wait for input and > periodically wake and check for interrupts. In that case the interrupt > will probably be seen sooner. > > If the interactive behavior is what you want you can add --interactive > to the arguments used to start R. > > Best, > > luke > > On Tue, 30 Apr 2019, Gábor Csárdi wrote: > > > OK, I managed to create an example without callr, but it is still > > somewhat cumbersome. Anyway, here it is. > > > > Terminal 1: > > mkfifo fif > > R --no-readline --slave --no-save --no-restore < fif > > > > Terminal 2: > > cat > fif > > Sys.getpid() > > > > This will make Terminal 1 print the pid of the R process, so we can > > send a SIGINT: > > > > Terminal 3: > > kill -INT pid > > > > The R process is of course still running happily. > > > > Terminal 2 again: > > tryCatch(Sys.sleep(10), interrupt = function(e) e) > > > > and then Terminal 1 prints the interrupt condition: > > > > > > This is macOS and 3.5.3, although I don't think it matters much. > > > > Thanks much! > > G. > > > > On Tue, Apr 30, 2019 at 9:50 PM Simon Urbanek > > wrote: > >> > >> Can you give an example without callr? The key is how is the process > >> stated and what it is doing which is entirely opaque in callr. > >> > >> Windows doesn't have signals, so the process there is entirely different. > >> Most of the WIN32 processing is event-based. > >> > >> Cheers, > >> Simon > >> > >> > >>> On Apr 30, 2019, at 4:17 PM, Gábor Csárdi wrote: > >>> > >>> Yeah, I get that they are async. > >>> > >>> What happens is that the background process is not doing anything when > >>> the process gets a SIGINT. I.e. the background process is just > >>> listening on its standard input. > >>> > >>> AFAICT for an interactive process such a SIGINT is just swallowed, > >>> with a newline outputted to the terminal. > >>> > >>> But apparently, for this background process, it is not swallowed, and > >>> it is triggered later. FWIW it does not happen on Windows, not very > >>> surprisingly. > >>> > >>> Gabor > >>> > >>> On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > >>> wrote: > > Interrupts are not synchronous in R - the signal only flags the request > for interruption. Nothing actually happens until R_CheckUserInterrupt() > is called at an interruptible point. In you case your code is apparently > not calling R_CheckUserInterrupt() until later as a side-effect of the > next evaluation. > > Cheers, > Simon > > > > On Apr 30, 2019, at 3:44 PM, Gábor Csárdi > > wrote: > > > > Hi All, > > > > I realize that this is not a really nice reprex, but anyone has an > > idea why a background R session would "remember" an interrupt (SIGINT) > > on Unix? > > > > rs <- callr::r_session$new() > > rs$interrupt() # just sends a SIGINT > > #> [1] TRUE > > > > rs$run(function() 1+1) > > #> Error: interrupt > > > > rs$run(function() 1+1) > > #> [1] 2 > > > > It seems that the main loop somehow stores the SIGINT it receives > > while it is waiting on stdin, and then it triggers it when some input > > comes in Maybe. Just speculating > > > > Thanks, > > Gabor > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > >>> > >> > > > > __ > > 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
