Hi all,
I’m using macOS Sierra (10.12.6) on a Macbook Pro. RStudio Version 1.1.423. I just installed rcpp and rstan from source. xtools has been updated today as well.
I am repeatedly getting a segfault (output below) but only when I run my Rnw (knitr) file. When I run the code chunk by chunk, it all works fine. If I run the stan model separately from the Rnw file and just try to save the fitted model and then load it into the Rnw file using load (i.e., I try to avoid fitting the model at all within the Rnw), I still get the same segfault. Weirdly, if I now move all my code into an Rmd file and run that file (with all the stan models in it), it works fine!
Here is the segfault message:
*** caught segfault ***
address 0x1126e4198, cause ‘memory not mapped’
Traceback:
1: .Call(list(name = “CppObject__finalize”, address = <pointer: 0x7f951081f7b0>, dll = list(name = “Rcpp”, path = “/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/libs/Rcpp.so”, dynamicLookup = TRUE, handle = <pointer: 0x7f9510831fb0>, info = <pointer: 0x1067ee1e0>), numParameters = 2L), <pointer: 0x7f950de12360>, .pointer)
2: x$.self$finalize()
3: (function (x) x$.self$finalize())()
An irrecoverable exception occurred. R is aborting now …
That is weird. I am going to guess that the background R process that does the knitting is finding a different version of some package than when you do it in an interactive session. Try
ip <- installed.packages()
dupes <- duplicated(ip)
if(any(dupes)) rownames(ip)[dupes]
to see if there are any packages you have installed multiple times in different directories.
Thanks. I tried this both on the console and within the Rnw (and checked the result after compiling) and there are no duplicates.
I think this problem is only happening for one particular set of Rnw files. If I compile some other paper in another directory, all Stan models run fine. Makes me think that maybe I have a .Rhistory or .Rdata or something hiding somewhere. But I don’t see any hidden files anywhere.
You can do in R
dir(getwd(), all.files = TRUE)
to see hidden files. You might also have an outdated .rda file that is getting picked up. Or perhaps you have cache = TRUE in your chunk options and the cache is corrupted somehow.
I think I have come closer to isolating the problem. I compiled the Rnw from the command line using Rscript, and everything compiles fine. This means it’s a problem with RStudio. But I couldn’t figure out why RStudio and rstan work fine when I compile some other document, but not the one I am working on. I restarted in a fresh directory, incrementally building up my document, but I still get the error. My problematic document is a book draft.
So essentially I am giving up and will just compile from the command line. I guess I should have written a Makefile in the first place, should stop using RStudio anyway and go back to emacs.
Wow, I lost two days just on this dumb problem.
Reminds me of the following:
3 Likes
I’m so sorry to hear that. Config issues like this are even more frustrating than programming issues.
If I understand correctly, your knitr document works OK running R from the command line, but not through RStudio.
P.S. My advice for debugging this kind of thing is to divide-and-conquer (I would say that as a computer scientist). Take the header of your doc and see if it works with just a title and some dummy text. Then insert things bit by bit until it breaks. You can also just keep cutting it in half until you get a minimal example that fails.
Yes, I agree this is a good strategy. This is what I tried, and this is how I lost a day or so. I figured out where the problems begin but not why. I guess if I spend enough time on it I will work it out, but it just doesn’t seem worth the effort any more. I have more important things to do so I just by-passed this by compiling from the command line. I’m at Henrik’s fifth stage of software development, the highest stage there is!
1 Like
That’s just level one. Then there’s C++. We regularly spend days trying to debug things that fail for one one compiler on one platform. Daniel and I would regularly go days without being able to get over compiler bugs.
