Skip to content

dump.frames and global environment

5 messages · Jannis, Henrik Singmann

#
Dear list members,


I am trying to use dump.frames to debug some code that i run non 
interactively. I use the following method:




dump.frames.mod = function() {
   dump.frames(dumpto = 'test', to.file = TRUE)
   quit(save = 'no', status = 10)
}

options(error = dump.frames.mod)


Is there any way to acess the content of the global environment from the 
*.rda file created in case of an error?

When I run the following, for example, I would like to access the 
contents of a,b and c from the debugging file:



dump.frames.mod = function() {
   dump.frames(dumpto = 'test', to.file = TRUE)
   quit(save = 'no', status = 10)
}

options(error = dump.frames.mod)


#uncomment with care:
#rm(list=ls())
a = 2
source('testscript.R', local = TRUE)

load('test.rda')
debugger(test)


testscript.R in this testcase contains:

b = 2
c = 3
plot(d)


The only way I found is wrapping a function around the lines of code but 
this would mean changing a lot of code.


Any Ideas?


Cheers
Jannis


 > sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-unknown-linux-gnu (64-bit)
#
Dear Jannis,

is there any specific reason you use dump.frames instead of recover? As far as I see it, options(error = recover) would allow to access the global environment.

And as ?recover tells you: "The use of recover largely supersedes dump.frames as an error option, unless you really want to wait to look at the error. If recover is called in non-interactive mode, it behaves like dump.frames. For computations involving large amounts of data, recover has the advantage that it does not need to copy out all the environments in order to browse in them. If you do decide to quit interactive debugging, call dump.frames directly while browsing in any frame (see the examples)."

However, as I haven't used dump.frames ever, this is not really an answer to your question.

Hope it helps,
Henrik


Am 24.07.2012 16:10, schrieb Jannis:

  
    
#
Thanks, Henrik for your reply. Well, the reason (until now) was that I 
thought recover would only work in interactive sessions. The question, 
however, no would be how to save the error object an daccess it later. 
Additionally, are you sure that the content of the global environment is 
saved with recover? The handling looks very much the same as browsing 
dum.frame objects.

Cheers
Jannis
On 24.07.2012 16:25, Henrik Singmann wrote:
#
I somehow was unsure whether or not your procedure was interactive or not. But when it is non-interactive, your problem remains: "If recover is called in non-interactive mode, it behaves like dump.frames" (and will likely not save the global environment."

The only othjer idea I have is that you could save the global environment occasionally in your script and load it with the dumpoed data:

save.image(file = "save.RData")

#after crash:

load("save.RData")

Best,
Henrik

Am 24.07.2012 17:45, schrieb Jannis:

  
    
#
Thanks again, Hendrik, for your help. Your suggestion would work. You 
could even wrap the save image and the dump.frames command in one 
function that is called when an error occours.

  I now, however, wrapped a dummy function around the call to source 
that starts my script and supplies a copy of the global environment to 
this function. As a result, i can access all neccessary objects while 
debugging. The open question to me is whether a default behaviour of 
dump.frames which saves the global anvironment automatically would help 
others as well .... ?


Cheers

Jannis
On 24.07.2012 17:58, Henrik Singmann wrote: