[Rd] RE: [R] [R] interaction of options(error=) and try(): was how to debug a sudden exit in non-interactive mode

Vadim Ogranovich vograno at evafunds.com
Tue Sep 7 00:41:46 CEST 2004


First of all let me thank Prof. Ripley and Peter Dalgaard for their
suggestions about ways to debug my initial problem. Debugger() suggested
by Prof. Ripley could have provided the definitive answer hadn't it
itself be somewhat flaky. Anyway it still helped a lot to pinpoint the

The problem turned out to be an old R "deficiency" that showed up again
when I used the mgcv package. In Jan 2003 I reported that even when an
error happens inside try() the error handler set by option(error=...)
would still be called (and it shouldn't). If the handler does something
non-local, e.g. quits via q(), then the function is given no chance to
recover. This is precisely what happened in my case.

The mgcv's function get.var() uses try() and then gracefully recovers
from the error, see a verbatim copy below:
get.var <- function (txt, data) 
    x <- data[[txt]]
    if (is.null(x)) {
        x <- try(eval(parse(text = txt), data, enclos = NULL), 
            silent = TRUE)
        if (inherits(x, "try-error")) 
            x <- NULL

However inside my .Rprofile I set
if (!interactive()) {
  options(error=quote({dump.frames(to.file=TRUE); q()}))
in order to use debugger() later on the dump. (I can no longer do it
since it breaks mgcv).

Back in 2003 I was told that this deficiency would go away when a new
more comprehensive mechanism would be implemented. Has it?

I thought I'd bring it up again since now it affects a recommended
package and therefore is less esoteric than my original example.


> -----Original Message-----
> From: Peter Dalgaard [mailto:p.dalgaard at biostat.ku.dk] 
> Sent: Friday, September 03, 2004 1:02 PM
> To: Prof Brian Ripley
> Cc: Vadim Ogranovich; r-help at stat.math.ethz.ch
> Subject: Re: [R] how to debug a sudden exit in non-interactive mode
> Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
> > If you look in ?debugger, especially right at the end, you will see 
> > how to attempt a post-mortem dump of the frams to a file.  If that 
> > gets run (and this might be a fatal error from C level, but 
> it is not 
> > reporting so), you can reload the dump and use debugger on it.
> > 
> > On Fri, 3 Sep 2004, Vadim Ogranovich wrote:
> [snip]
> > > # Here I run it non-interactively from the shell. Note 
> that the last 
> > > line, cat("after\n"), doesn't get executed. (it does get 
> executed in 
> > > the interactive mode or with --no-init-file) ~% R --no-save 
> > > --no-restore --silent < debug.R
> Also, with an invocation like that, you can run under the debugger as
> follows: 
>   $ R -d gdb
>   (gdb) run --no-save --no-restore --silent < debug.R
> and maybe set a breakpoint in the error handler, or just let 
> it run to completion and see if it segfaults or something.
> -- 
>    O__  ---- Peter Dalgaard             Blegdamsvej 3  
>   c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
>  (*) \(*) -- University of Copenhagen   Denmark      Ph: 
> (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: 
> (+45) 35327907

More information about the R-devel mailing list