Skip to content

"Error: bad value" problem

11 messages · Richard E. Chandler, Peter Dalgaard, Rolf Turner +3 more

#
Dear R-help,

Like several other subscribers, I have recently encountered a problem 
whereby R will execute code apparently correctly and without error, 
but any subsequent command will yield "Error: bad value" so that R 
has to be killed and restarted. We have checked this out with a few 
different operating systems (Windows XP/Vista and Linux) and with 
different versions of R. We have established the following:

1.	The error occurs with versions of R from 2.5.0 onwards on all the 
OSs we have tried, but not with earlier versions of R.
2.	The error is not reproducable between machines - identical code 
will fail at different points on two different machines.
3.	The error is not related to contributed packages, because our code 
doesn't use any. The code *does*, however, use repeated calls to 
optim() and nlm(), and passes several arguments through a sequence of 
functions using "...".
4.	Occasionally, we get an error relating to subset replacement 
instead of "Error:bad value". For example:

 > x <- rnorm(10)
 > x[1] <- 3
Error in x[1] <- 3 : could not find function "[<-"

5.	The error behaviour changes as a result of minor modifications to 
print() statements in the code e.g. by inserting a line that prints 
the value of a well-defined variable.

I suspect this really *is* a bug (particularly since it only started 
happening with version 2.5.0), but I figure it would be worth giving 
people a chance to tell me I'm an idiot before reporting it as such. 
In case anybody would like to try and see the error for themselves, I 
have uploaded some files to 
http://www.homepages.ucl.ac.uk/~ucakarc/Rtest/. The file ErrorDemo.r 
is the main script - see the file header there for more details. 
Files momfit.r and elmstats.dat are also required for this example to 
work. I'm sorry that it isn't a very simple example, but I haven't 
seen a simple illustration of the problem (and I couldn't find any 
examples in the list archives either).

With best wishes to all,
Richard
=====================================================================
			Richard E. Chandler
			^^^^^^^^^^^^^^^^^^^
Room 135, Dept of Statistical Science, University College London,
1-19 Torrington Place, London WC1E 6BT, UK
Tel: +44 (0)20 7679 1880		Fax: +44 (0)20 7383 4703

Internet: http://www.ucl.ac.uk/Stats       		(department)
           http://www.homepages.ucl.ac.uk/~ucakarc	(personal)
email:    richard at stats.ucl.ac.uk
#
On 18/12/2008, at 11:34 AM, Richard E. Chandler wrote:

            
I can confirm that the error occurs.

I downloaded the files and sourced ``ErrorDemo.R''. Doing x <- rnorm(10)
after doing so triggered the error.  Subsequently attempting traceback()
(or anything else) simply triggered the error again.

Good luck to R Core in tracking this down!

	cheers,

		Rolf Turner

######################################################################
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
#
Rolf Turner wrote:
Unfortunately, there's at least on R Core member for which it does NOT 
happen... Fedora 9 i686, R 2.8.0 and 2.8.1 RC (2008-12-15 r47214)
#
On 17/12/2008 5:34 PM, Richard E. Chandler wrote:
The symptoms you describe suggest an out of bounds read or write. 
Unfortunately, I don't see the error, in R-devel or R 2.8.0.

Tracking this sort of bug down on Windows is pretty hard, because as far 
as I know valgrind doesn't run on Windows, and I don't know of any 
Windows equivalent that supports gcc.

So I'm not going to be able to help...other than to suggest reducing the 
example to something that runs quickly, then try running it after 
running gctorture().  That often flushes out hard to reproduce bugs, but 
it goes very slowly...

Duncan Murdoch
#
On 18/12/2008, at 1:09 PM, Peter Dalgaard wrote:

            
<snip>
I should've included my session info:

R version 2.8.0 (2008-10-20)
i386-apple-darwin8.11.1

locale:
C

attached base packages:
[1] datasets  utils     stats     graphics  grDevices methods   base

other attached packages:
[1] misc_0.0-9     fortunes_1.3-5 MASS_7.2-44

So it's happening to me with R 2.8.0 --- but under Mac OSX, rather than
Fedora.

	cheers,

		Rolf

######################################################################
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
#
Peter Dalgaard wrote:
Wrong, actually... It did happen when run with 2.8.0 and valgrind (but 
not without it). Unfortunately there were no errors from valgrind.... 
yuck!!!

....
 > a
Error: bad value
 >
 >
Save workspace image? [y/n/c]: n
==29050==
==29050== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 116 from 1)
==29050== malloc/free: in use at exit: 13,984,907 bytes in 10,061 blocks.
==29050== malloc/free: 117,023 allocs, 106,962 frees, 93,104,003 bytes 
allocated.
==29050== For counts of detected errors, rerun with: -v
==29050== searching for pointers to 10,061 not-freed blocks.
==29050== checked 14,502,208 bytes.
==29050==
==29050== LEAK SUMMARY:
==29050==    definitely lost: 0 bytes in 0 blocks.
==29050==      possibly lost: 0 bytes in 0 blocks.
==29050==    still reachable: 13,984,907 bytes in 10,061 blocks.
==29050==         suppressed: 0 bytes in 0 blocks.
==29050== Rerun with --leak-check=full to see details of leaked memory.
[
#
I can get the errors to happen on Ubuntu 8.10 with R --vanilla (*without*
valgrind) -- but
editing momfit.r line 742 so that plot.progress=FALSE seems to make the
problem go away.  (This was a lucky guess, it looked like there was
something
odd going on with the plots.)

  Hope that helps someone ...

  Ben Bolker
R version 2.8.0 (2008-10-20) 
i486-pc-linux-gnu 

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
#
Ben Bolker wrote:
Probably not. The problem is to reproduce the error state in a way so 
that we can understand what is causing it.

I can debug this to
(gdb) bt
#0  Rf_error (format=0x8220c65 "bad value") at 
../../../R/src/main/errors.c:704
#1  0x0805a924 in SETCDR (x=0x8f89348, y=0x9b276e8)
     at ../../../R/src/main/memory.c:2728
#2  0x0819fa46 in GrowList (l=0x951e8f4, s=<value optimized out>) at 
gram.y:958
#3  0x081a2a7b in xxvalue (v=0x8f89348, k=4, lloc=<value optimized out>)
     at gram.y:440

and the problem in GrowList is that CAR(l) is R_NilValue (==0x8f89348), 
which supposedly "cannot happen", and the thing that calls GrowList is 
something with srcrefs (DuncanM?).

Digging deeper probably has to wait till the weekend for my part. (The 
natural next step is figuring out how the R_NilValue got into that 
location, but I should try to sleep off this cold....)

I'm CCing r-devel on this. Can we move the discussion there?

  
    
#
On 17/12/2008 8:56 PM, Peter Dalgaard wrote:
I can probably take a look tomorrow.  I wasn't getting an error, but 
maybe I'll see the same corruption if I watch it run.

Duncan Murdoch
#
On 17/12/2008 9:47 PM, Duncan Murdoch wrote:
I had time to see if I was getting a NilValue there tonight, and the 
answer was no, with the Windows RC.  I don't get the error in any 
version I've tried on Windows, though I can see it in 2.8.0 on MacOSX.

Duncan
#
This has all the hallmarks of a bug I found and fixed in R-devel
(r46998).  I did not port the patch over to the R release branch because
I could not reproduce the bug.

In R-devel, I was seeing problems with "make test-Segfault". This would
occasionally segfault, but most of the time would create the "bad value"
error, and of course would also run perfectly fine a lot of the time.
The error came from exactly the same place that Ben found.  It was due
to an invalid SrcRefs being used because SrcFile is not set to zero when
it should be.

I'll have a look and see if it is the same problem, or a close cousin.

Martyn
On Wed, 2008-12-17 at 22:07 -0500, Duncan Murdoch wrote:
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}