search for: r_toplevelexec

...uses longjmps on error and interrupts as well as for condition handling and it is undefined behaviour to do a longjmp from one thread to another; interrupts can be suspended before creating the threads by setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only works corr...

Hello, I?m trying to leverage R_ToplevelExec to implement C level try/catch. The way it is implemented allows for running a function in a top level context. This context gets an empty handler stack, so either the function runs correctly or it jumps. When it jumps, it does not find a handler, so it jumps to the top level context. R does no...

...know that I would have the level of confidence yet that we haven't missed an important point that I would want before going down this route. Losing stack checking is risky; it might be eventually possible to provide some support for this to be handled via a thread-local variable. Ensuring that R_ToplevelExec can't jump before entering the body function would be a good idea; if you want to propose a patch we can have a look. Best, luke On Sun, 19 May 2019, Andreas Kersting wrote: > Hi, > > As the subject suggests, I am looking for the most robust way to call an (arbitrary) function from...

Hello! This is my first post here. I came across the very same problem. It can be reproduced within modified tests/Embedding/RParseEval.c Actually this example has another issue, namely it doesn't wrap everything in R_ToplevelExec . This is a major show stopper for newcomers as that function is barely mentioned anywhere and longjmp into terminated setuploop function followed by R_suicide look like a mystery. Error: bad value Fatal error: unable to initialize the JIT That aside, here is the code with newlines that fails to...

...; /bin/pwd`/lib -lR gcc -o Rtest Rtest.o embeddedRCall.o -L/autofs/tewa_data5/ost/R/R-2.3.0/lib -lR -Wl,--rpath -Wl,/data5/ost/R/R-2.3.0/lib embeddedRCall.o(.text+0x1e): In function `Test_tryEval': /autofs/tewa_data5/ost/R/R-2.3.0/tests/Embedding/embeddedRCall.c:81: undefined reference to `R_ToplevelExec' collect2: ld returned 1 exit status make: *** [Rtest] Error 1 ost at hawk0:/data5/ost/R/R-2.3.0/tests/Embedding> cd /autofs/tewa_data5/ost/R/R-2.3.0/lib ost at hawk0:/autofs/tewa_data5/ost/R/R-2.3.0/lib> nm libR.so | grep R_Top 000000000042c920 B R_Toplevel 000000000042cae8 B R_Toplevel...

...uses longjmps on error and interrupts as well as for condition handling and it is undefined behaviour to do a longjmp from one thread to another; interrupts can be suspended before creating the threads by setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow >> 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only wo...

...uses longjmps on error and interrupts as well as for condition handling and it is undefined behaviour to do a longjmp from one thread to another; interrupts can be suspended before creating the threads by setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow > > 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only...

...z.ch/pipermail/r-devel/2008-August/050332.html At this point, I would like to report two bugs in "Writing R Extensions" documentation. From that document it is not clear why line feeds (0x0A) have to be removed from the input string to be parsed. Also nowhere in that document it mentions R_TopLevelExec if parsing needs to be done in the outer context. That is not when our C function is called from R, but when we are trying to parse R code in C directly outside of main loop. These are big show stoppers for newcomers. The barely modified test code I had in my previous post, does not parse what wou...

Is there any way to distinguish between an error and a user interruption in R_tryEval? In both cases the ErrorOccurred argument is set to 1. For my application I need a different action in case of a SIGINT. >From the source code I infer that R_tryEval basically wraps eval in R_ToplevelExec, which returns TRUE if fun returns normally, FALSE if it results in a jump to top level. However both an error and SIGINT result in a jump. Is there an alternative method, or some method of finding out which is the two happened after calling R_tryEval? One thing I tried is see if R_curErrorBuf() i...

Hello, When using R_tryEval (from JRI in my case), is there a way to setup error recovery strategy and more generally calling handlers. From my reading of context.c, R_tryEval calls R_ToplevelExec which creates a context like this: begincontext(&thiscontext, CTXT_TOPLEVEL, R_NilValue, R_GlobalEnv, R_BaseEnv, R_NilValue, R_NilValue); so I guess what I am trying to do is add "cend" and/or "handlerstack" to this context. Is this possible ? Are there exam...

...(call=0x16c6c50, op=0x1446638, arglist=0x16c6b70, rho=0x53dd90, suppliedenv=0x53ddc8) at eval.c:861 #21 0x00002aaaaafd621b in Rf_eval (e=0x16c6c50, rho=0x53dd90) at eval.c:512 #22 0x00002aaaaaf8738e in protectedEval (d=<value optimized out>) at context.c:747 #23 0x00002aaaaaf87cfe in R_ToplevelExec (fun=0x2aaaaaf87370 <protectedEval>, data=0x7fffffffde00) at context.c:702 #24 0x00002aaaaaf87d89 in R_tryEval (e=<value optimized out>, env=<value optimized out>, ErrorOccurred=0x61) at context.c:761 #25 0x00002aaaaadeb109 in executeText ( prog=0x7fffffffe0a0 "*r...

...s is happening because findFun() was not executed inside a valid context, and therefore R_ToplevelContext->cjmpbuf is invalid. My question is -- is the above an abuse of findFun() by RNamedCall.c (meaning I should avoid the same pattern)? Or maybe it should be wrapped in something similar to R_ToplevelExec? ========================== On a related note, I found during my PL/R debugging that the segfault was causing the same console based, interactive, "*** caught segfault ***" logic to execute. I was able to confirm that R_Interactive was set to TRUE in my PL/R session. It seems that R...

...s perfectly ok, they also may use internal API that is indeed not documented e.g. in Writing R Extensions. Note Writing R Extensions has a section on embedding R and on cleanup handlers. Best Tomas > > Actually this example has another issue, namely it doesn't wrap > everything in R_ToplevelExec . This is a major show stopper for > newcomers as that function is barely mentioned anywhere and longjmp into > terminated setuploop function followed by R_suicide look like a mystery. > > Error: bad value > Fatal error: unable to initialize the JIT > > > That aside, here is...

Hi, An R package on which I am working makes a series of very computationally-intensive and complex .C() calls, that I would like to make interruptible. However, calling R_CheckUserInterrupt() causes a non-local exit, so the memory allocated by malloc() is never freed. The way the code is structured, it might not be practical to replace all the malloc() calls with R_alloc() calls. The question

.../usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac)[0xb7cc9e5c] > /usr/lib/R/lib/libR.so(Rf_eval+0x349)[0xb7cc61d9] > /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac)[0xb7cc9e5c] > /usr/lib/R/lib/libR.so(Rf_eval+0x349)[0xb7cc61d9] > /usr/lib/R/lib/libR.so[0xb7c75b89] > /usr/lib/R/lib/libR.so(R_ToplevelExec+0xb8)[0xb7c763b8] > /usr/lib/R/lib/libR.so(R_tryEval+0x3e)[0xb7c7643e] > > /usr/lib/R/site-library/RGtk2/libs/RGtk2.so(R_GClosureMarshal+0x86)[0xb6ff18c6] > /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759] > /usr/lib/libgobject-2.0.so.0[0xb68bbd1d] > /usr/lib/libgo...

...al + 1356 16 libR.dylib 0x0367932c do_begin + 108 17 libR.dylib 0x03676fbc Rf_eval + 1356 18 libR.dylib 0x0367ad10 Rf_applyClosure + 1120 19 libR.dylib 0x03676e3c Rf_eval + 972 20 libR.dylib 0x0361b7c0 protectedEval + 64 21 libR.dylib 0x0361c170 R_ToplevelExec + 544 22 libR.dylib 0x0361c22c R_tryEval + 60 23 _rpy2031.so 0x032f0b8c do_eval_expr + 108 >> 24 _rpy2031.so 0x032ef950 Robj_call + 688 25 Python2.5 0x023c6c08 PyObject_Call + 56 26 Python2.5 0x024a68ec PyEval_EvalFrameEx + 16844 27 Python2.5...

...al + 1356 16 libR.dylib 0x0367932c do_begin + 108 17 libR.dylib 0x03676fbc Rf_eval + 1356 18 libR.dylib 0x0367ad10 Rf_applyClosure + 1120 19 libR.dylib 0x03676e3c Rf_eval + 972 20 libR.dylib 0x0361b7c0 protectedEval + 64 21 libR.dylib 0x0361c170 R_ToplevelExec + 544 22 libR.dylib 0x0361c22c R_tryEval + 60 23 _rpy2031.so 0x032f0b8c do_eval_expr + 108 >> 24 _rpy2031.so 0x032ef950 Robj_call + 688 25 Python2.5 0x023c6c08 PyObject_Call + 56 26 Python2.5 0x024a68ec PyEval_EvalFrameEx + 16844 27 Python2.5...

...te an R level object and attach a finalizer to the object that will arrange for the GC to close the file at some point in the future if a non-local exit occurs. Search developer.r-project.org for finalization and weak references for some info on this. One other option is to use the R_ToplevelExec function. This has some drawbacks since it effectively makes invisible all other error handlers, but it is an option. It is also not officially documented and subject to change. > And I think it makes relevant again the question I asked in another > related thread: how is memory...

...d.c:363 #4 0xb74e159e in RTcl_eventProc (evPtr=0x97dfbf0, flags=-1) at tcltk_unix.c:136 #5 0xb749d6a3 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so.0 #6 0xb749da32 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so.0 #7 0xb74e14ee in TclSpinLoop (data=0x0) at tcltk_unix.c:60 #8 0x0814d4a6 in R_ToplevelExec (fun=0xb74e14d0 <TclSpinLoop>, data=0x0) at context.c:604 #9 0xb74e14b2 in TclHandler () at tcltk_unix.c:67 #10 0x08184f11 in R_CheckUserInterrupt () at errors.c:125 #11 0x0818d5cc in Rf_eval (e=0x8ab3010, rho=0x858f6f8) at eval.c:370 ... (snip)... Many Rf_eval, Rf_applyClosure, etc. #73...

...ibrary interface that has a 'open' and 'close' step, the same sort of issue will arise. What I believe we should do, and what Rcpp has made steps towards, is make it possible to interact with some subset of the R API safely from C++ contexts. This has always been possible with e.g. R_ToplevelExec() and R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). In theory, as a prototype, an R package could provide a 'safe' C++ interface to the R API using R_UnwindProtect() and friends as appropriate, and client packages could import and link to that package to gain a...