3

Got the dreaded message (its my replacement for the blue screen of death =). The second to top item on the stack trace is a do.call(...) call, which is automatically printed. The top of the stack seems to be cutoff because all I can see is what looks like data:

 ...1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L,     1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L,     1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L)))
     2: do.call(functionToTest, c(thisTestCaseParameters, fixedParameterValues))

traceback give me no further information than the do.call call

So it must be that something in functionToTest puked. How do I figure out where that is? Is there a way to look deeper into the top of the stack? functionToTest is a function that calls other functions and so on. I'm trying to isolate the issue so I can report it, but I don't know how.

Suraj
  • 35,905
  • 47
  • 139
  • 250
  • If you can predictably recreate the error, then setting `options(error=recover)` or `options(error=dump.frames)` ([as described, e.g., here](http://stackoverflow.com/questions/8507442/error-without-an-error-being-thrown)) might get you some useful information. Both will allow you to poke around the several contexts on the frame stack, after the error is thrown. If the error only happens once in a blue moon, you could perhaps just leave `options(error=dump.frames)` set, and only ever examine `last.dump` when the particular error you're being bugged by occurs. – Josh O'Brien Mar 07 '12 at 22:06
  • Thanks, Josh. I might just leave options(error=dump.frames) on because I cannot predictably recreate the error. It seems to with functions that take a long time to execute and use a decent chunk of memory – Suraj Mar 09 '12 at 15:27

2 Answers2

1

I have received this error prior to the frying of memory module on my Windows 2008 R2 64bit box. I was performing a memory intensive task using the rgeos package; memory intensive because this package suffers from a memory leak in the GEOS C library to which it is attached. Despite attempts to fix leak it still persists.

I am guessing that I received this error both because of the failing memory module and the intensive drain on memory that this memory leak was causing.

I should note that memory module has now been removed, and I perform identical analyses with this still memory-leaky package, and I have never since received the error.

Please consider the possibility that this is a hardware issue, and that your code is somehow stimulating it. A key indication of this would be that it sometimes works ... but not necessarily as memory can be pernicious in my experience.

You can take the following steps to rule out/rule in this possibility:

  1. Run the offending procedure and observe memory usage, using Resource Monitor or other equivalent software. Is it unusually high for the R process?

  2. Using options(error=recover) and add some iterator to your code that can mark the progress of a loop that is presumably in operation. Does it crash at the same point every time, or does it differ? If it differs for the identical conditions, this suggests that randomness of a hardware error.

  3. If these steps indicate something random, then take steps to examine your memory health. There are numerous discussions of how to do this on StackExchange SuperUser.

digitalmaps
  • 2,885
  • 3
  • 22
  • 28
  • I hadn't thought to check physical memory issues. I ran a scan over night but it didn't complete so I'll run one over the weekend and report back. good suggestion! – Suraj Mar 09 '12 at 15:26
  • memtest doesn't always pick up these intermittent sorts of memory errors in my experience. But I guess this is the next thing to try. – digitalmaps Mar 09 '12 at 15:39
  • thanks, Paul. I didn't get a chance to run the memory test, but your post is the best suggestion so far, so I'll award you the bounty and keep the question open until I can dig deeper. thanks! – Suraj Mar 13 '12 at 16:46
  • Great! Good luck solving it. Unless there is anything stochastic embedded in your code, a randomly occurring error sounds very suspicious. – digitalmaps Mar 13 '12 at 17:41
0
?traceback
?browser

Except that is for R errors. I wonder if you are getting an OS generated message, and for that possibility you have definitely not provided sufficient information for anyone to be helpful.

IRTFM
  • 258,963
  • 21
  • 364
  • 487
  • DWin - How specifically would you use browser or traceback after an access violation? I called traceback but there was no information higher in the stack than the do.call call. My question is what tecniques can be used after an access violation to pinpoint the source of the violation. This access violation is not easily reproduced. As I said, functionToTest calls other functions (and so on). So I've admitted that I don't know where the error occurs, I'm looking for a technique to identify the source of the error. – Suraj Dec 23 '11 at 14:12
  • 2
    I've never gotten such a message, and as I said, I'm not sure it's coming from R. Was my hint that you needed to provide OS specifics too subtle? – IRTFM Dec 23 '11 at 14:42
  • I'm running windows 7 x64. Does that provide a different technique for debugging? I'm not sure what you mean by "coming from R", this is an access violation in R, so either its an issue with R or a package, right? – Suraj Dec 23 '11 at 15:53
  • R causing an error reported by the OS would be different in my mind than "coming from R", however this page has that message and shows that it is also "coming from R": http://svn.r-project.org/R/trunk/src/main/main.c – IRTFM Dec 23 '11 at 18:30