[Rd] Reproducible use case for R crash after updating R

Mark.Bravington at csiro.au Mark.Bravington at csiro.au
Tue May 17 14:33:59 CEST 2011


The ability to do a "wounded load", when a proper load() can't be completed but you still want as much of the stuff as possible, would be very useful. In my experience, the trouble has invariably been a missing namespace, eg (as in Henrik's example) from a package that can't be found. That's OK if the package can be identified and updated. But sometimes it can't be-- maybe it just doesn't exist for the latest greatest version of R, or the developer has decided to work in Q instead, or the internet is having a bad day. If there are lots of useful objects in the .RData, but a few things that won't load, it's pretty bad to lose the whole lot. So triggering an comprehensible error is useful for the specific case Henrik gives, but if this is being looked at anyway, perhaps more could be done.

How about giving load() an optional argument, such that if a (namespace?) environment is sought but can't be found, then it is replaced with emptyenv(), with a warning. That should stop catastrophic behaviour later on.

I wonder whether the "refhook" argument of 'unserialize' could somehow be perverted into doing this? Dunno, just a thought.

There might be other things besides missing packages that could cause a load() to fail, but I think all the cases I've come across have come down to that. It can be pretty hard to track down the problem, or worse than hard.

Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
________________________________________
From: r-devel-bounces at r-project.org [r-devel-bounces at r-project.org] On Behalf Of Duncan Murdoch [murdoch.duncan at gmail.com]
Sent: 17 May 2011 20:54
To: Henrik Bengtsson
Cc: R-devel
Subject: Re: [Rd] Reproducible use case for R crash after updating R

On 11-05-16 11:59 PM, Henrik Bengtsson wrote:
> Great, thanks for this.
>
> On Fri, May 13, 2011 at 2:34 PM, Duncan Murdoch
> <murdoch.duncan at gmail.com>  wrote:
>> A simple version of a fix is now in R-devel:  if the .RData file can't be
>> loaded during startup, an error message is printed, and R starts with an
>> empty workspace.
>
> I've just verified with the R v2.14.0 devel (2011-05-16 r55916) on
> Windows.  For followers, here it is how it works now:
>
> # GENERATE AN INVALID .RData file:
> install.packages("fortunes")
> library("fortunes")
> foo<- fortune
> remove.packages("fortunes")
> q("yes")
>
> Startup behavior when using either Rterm or Rgui:
> [...]
> Type 'q()' to quit R.
>
> Error in loadNamespace(name) : there is no package called 'fortunes'
> During startup - Warning message:
> unable to restore saved data in .RData
>> cat("Hello world!\n")
> Hello world!
>>
>
>>
>> The name of the .RData file is printed.  It's usually just ".RData", because
>> that's what R tries to load; the file will be in the current directory if
>> you want to delete it.
>
> I've looked at the code behind this and I kind of understand what you
> mean by "just" .RData.  However, is there a reason for not reporting
> the full pathname to .RData, e.g. file.path(getwd(), ".RData")?  It
> would help the user further if the warning said:

This is coming from C code, so getting the current directory requires
allocating memory for a buffer.  We're in a situation where something
that normally succeeds has just failed, so it might not be safe to do that.

> (1) unable to restore saved data in .RData in directory /path/to/pwd/
> (2) unable to restore saved data in /path/to/pwd/.RData

If the file that it tried to load was named "/path/to/.RData", then your
messages wouldn't be right:

  (1) unable to restore saved data in /path/to/.RData in directory
/path/to/pwd/
  (2) unable to restore saved data in /path/to/pwd//path/to/.RData

You really want something like normalizePath(), but that's not a simple
C function (and it has its own problems, e.g. if the file doesn't exist,
normalizePath doesn't work, at least on Windows).

Duncan Murdoch


> BTW, the following will not be correct if the working directory is
> changed by one of the .Rprofile startup scripts:
>
> (2) unable to restore saved data in .RData in the current working
> directory, cf. getwd()
>
> Thanks again
>
> /Henrik
>
>>   If it contains objects that you want to recover, you
>> can try to deal with the error message (e.g. by installing fortunes in your
>> example), exiting without saving, and then the next restart may succeed.
>>
>> Duncan Murdoch
>>
>>
>> On 11-05-12 2:26 PM, Henrik Bengtsson wrote:
>>>
>>> On Thu, May 12, 2011 at 10:55 AM, Henrik Bengtsson<hb at biostat.ucsf.edu>
>>>   wrote:
>>>>
>>>> This might have been discussed before, but below is a
>>>> "not-so-unlikely" use case where the user follows normal procedures,
>>>> updates R to a major release version, and then R crashes:
>>>>
>>>> 1. Use runs R stable (e.g. v2.13.0).
>>>> 2. User installs a package with a namespace, e.g.
>>>> install.packages("fortunes").
>>>> 3. User uses the package and one of the package's objects are assigned
>>>> to the global env, e.g. foo<- fortune.
>>>> 4. The user quits R and stores the session data, e.g. q("yes").  The
>>>> session is stored in users home directory.
>>>> 5. User update to new major release of R (e.g. 2.14.0).
>>>> 6. User starts R.  R crashes with "Fatal error: unable to restore
>>>> saved object in .RData" because 'fortunes' is not installed for this
>>>> new version of R.  There is also an error message before that
>>>> reporting "Error in loadNamespace(name) : there is no package called
>>>> 'fortunes'".
>>>>
>>>> This can also be reproduced using a single R version as follows:
>>>>
>>>> 1. Start R and do:
>>>> install.packages("fortunes")
>>>> library("fortunes")
>>>> foo<- fortune
>>>> remove.packages("fortunes")
>>>> q("yes")
>>>> 2. Restart R.  R crashes.
>>>>
>>>> For a GUI-only user this is complicated, because although the users
>>>> sees the informative error message that "Error in loadNamespace(name)
>>>> : there is no package called 'fortunes'", s/he cannot get to the point
>>>> where it is possible to install that missing package.  The key for the
>>>> user is to understand to remove the .RData.  In order to do this, s/he
>>>> has to locate that file first.
>>>>
>>>> To simplify this, a few alternatives exists:
>>>>
>>>> 1. R reports the full path to the problematic .RData file.
>>>> 2. R renames the problematic .RData file to
>>>> erroneous_20110512-123404UTC.RData and reports the new full pathname.
>>>>
>>>> In both cases there could be the option for R to either exit, or
>>>> ignore the problematic .RData file and give the user access to the
>>>> prompt.  One could also imaging a fancy recovery feature where R
>>>> detects "erroneous" .RData files and asks the user if s/he wish to try
>>>> to load them (maybe the packages has been installed since).
>>>
>>> On Windows, the easiest way to give a GUI-only user access to the R
>>> prompt is to also install an "R (vanilla mode)" shortcut/icon on the
>>> Startup menu and Desktop (with target "...\Rgui.exe" --vanilla) in
>>> addition to the default one.
>>>
>>> /Henrik
>>>
>>>>
>>>> I'm sure there are complications to implement the above, because
>>>> .RData is loaded during startup, but that's my $.02 to this problem
>>>>
>>>> /Henrik
>>>>
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list