On 5/6/07, Jeffrey Horner <[EMAIL PROTECTED]> wrote:
> Luke Tierney wrote:
[...]
> >> Is there a reason R_ProcessEvents cannot be set on Unix but can on
> >> Mac? It doesn't seem user-settable on Windows, but whatever the built
> >> in default is seems to handle the Qt event loop. And for that matter,
> >> why is it possible to set the file.edit callback on Mac but not Linux?
> >> This seems arbitrary, and no explanation is given (that I could find).
> >
> > The R_PRocessEvents callback may be settable on MacOS but I'm not sure
> > it's used -- at least a quick grep didn't reveal its use anywhere
> > outside the gnuwin32 code.
I meant the callback ptr_R_ProcessEvents (in Rinterface.h). The Mac
GUI source has (this is probably not the latest version):
[EMAIL PROTECTED]:~/Mac-GUI-1.17$ grep -i ptr_r_process */*
REngine/Rinit.c:extern void (*ptr_R_ProcessEvents)();
REngine/Rinit.c: ptr_R_ProcessEvents = Re_ProcessEvents;
and R/trunk/src/unix/aqua.c has:
void R_ProcessEvents(void)
{
if(!useaqua){
if (R_interrupts_pending)
onintr();
return;
} else
ptr_R_ProcessEvents();
}
> > It would be good to unify the Mac and *nix mechanisms here since the
> > OS underpinings are now so similar, but it will have to get high
> > enough on someone's priority list to happen.
[...]
> >> The problem I'm having with this solution is that whenever I interrupt
> >> a graphics command, R crashes. This is true for commands being
> >> evaluated by R_tryEval, but not those run from the REPL (for example,
> >> if I make the call inside a debug() environment, interrupting it
> >> causes no problems). As far as I can tell, this is only a problem with
> >> graphics; other commands can be interrupted even when run using
> >> R_tryEval().
> >
> > That sounds like a longjmp being done to a place that doesn't exist --
> > maybe a threading issue in Qt. See what gdb tells you about where the
> > crash is occurring. It might be different for onintr and kill. You
> > might also try just setting the R_interrupts_pending flag from the
> > interrupt event handler rather than calling onintr (which probably
> > longjmp's) or kill (which may be doing something you don't want if
> > other threads with other signal handlers are involved).
I will have to start learning about gdb sometime soon, but in this case, the
problem seems to be due to the interaction of R_tryEval() and
graphics, and has nothing to do with interruptions. Here's a variant
of the trEval test case that triggers a legitimate error caused by
grid.text('foo', gp = gpar(font=1, fontface=1))
[EMAIL PROTECTED]:~$ cat tryEvalGraphics.c ## beware of line wrapping
/*
Compile this as:
RPROG=R-devel
export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib:\${LD_LIBRARY_PATH}
gcc `${RPROG} CMD config --cppflags` \
`${RPROG} CMD config --ldflags` \
-o tryEvalGraphics tryEvalGraphics.c
*/
#include <Rinternals.h>
#include <Rembedded.h>
#include <R_ext/Parse.h>
int
main(int argc, char *argv[])
{
SEXP e, val;
int i, errorOccurred;
ParseStatus status;
char *cmds[] = {
"library(lattice)",
"library(grid)",
"grid.text('foo', gp = gpar(font=1, fontface=1))",
"xyplot(1 ~ 1, panel = function() grid.text('foo', gp =
gpar(font=1, fontface=1)))"
};
argv[0] = "R";
Rf_initEmbeddedR(argc, argv);
for (i = 0; i < 4; i++) {
printf("** I **: Executing command: %s\n", cmds[i]);
fflush(stdout); sleep(1);
PROTECT(e = R_ParseVector(mkString(cmds[i]), -1, &status, R_NilValue));
val = R_tryEval(VECTOR_ELT(e, 0), NULL, &errorOccurred);
if (errorOccurred) { Rprintf("Error executing: %s\n", cmds[i]); }
else Rf_PrintValue(val);
UNPROTECT(1);
printf("** I **: Succeeded\n");
fflush(stdout); sleep(1);
}
Rf_endEmbeddedR(0);
return(0);
}
Running this, I get:
[EMAIL PROTECTED]:~$ R-devel CMD ./tryEvalGraphics
R version 2.6.0 Under development (unstable) (2007-05-04 r41439)
[...]
[Previously saved workspace restored]
** I **: Executing command: library(lattice)
[1] "stats" "graphics" "grDevices" "utils" "datasets" "lattice"
[7] "rcompgen" "methods" "base"
** I **: Succeeded
** I **: Executing command: library(grid)
[1] "grid" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "lattice" "rcompgen" "methods" "base"
** I **: Succeeded
** I **: Executing command: grid.text('foo', gp = gpar(font=1, fontface=1))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
Error executing: grid.text('foo', gp = gpar(font=1, fontface=1))
** I **: Succeeded
** I **: Executing command: xyplot(1 ~ 1, panel = function()
grid.text('foo', gp = gpar(font=1, fontface=1)))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
*** caught segfault ***
address 0x22000440, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
[EMAIL PROTECTED]:~$
Note that the first error (which doesn't actually get around to
starting a device) is handled properly, while the second is not.
[...]
> Deepayan, this is your code from quter-20070502 below, where R_tryEval
> is called:
>
> PROTECT(cmdSexp = mkString(cmd));
> PROTECT(cmdExpr = R_ParseVector(cmdSexp, -1, &status, R_NilValue));
> if (status == PARSE_OK) {
> int i, errorOccurred;
> for(i = 0; i < length(cmdExpr); i++) {
> ans = R_tryEval(VECTOR_ELT(cmdExpr, i),
> NULL, &errorOccurred);
> }
> if (errorOccurred) ans = R_NilValue;
> UNPROTECT(2);
>
> Question: is each element of cmdExpr actually on the protection stack?
> Or rather, is the caller guaranteed that the cmdExpr element will not be
> garbage collected? My assumption is yes, since cmdExpr is, but I could
> be wrong.
Normally I would say yes, because my understanding is that
sub-elements of protected SEXP's are supposed to be automatically
protected. But I don't really know what happens when there is an
error. On the other hand, I haven't been seeing any errors (other than
the graphics one described above) recently with that code.
One possibly relevant factoid: a few days ago I was trying to play
with R_topLevelExec(), and that seemed to require an extra UNPROTECT()
for no reason (there's a similar hack in rkward). I sort of got it
working, but two consecutive errors reproducibly took me to a
situation where the same error message would get repeated whatever I
did after that. I didn't pursue this because I figured out an
alternative solution to my problem.
-Deepayan
> Just curious because I just ran into troubles with calling
> R_tryEval with unprotected expressions and accepting signals. I
> witnessed what Luke explained above, that longjmp's were being done to a
> place that I wasn't anticipating, e.g. R_tryEval was never returning.
>
> Jeff
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
