Segfault

#1

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 …

#2

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.

#3

Thanks. I tried this both on the console and within the Rnw (and checked the result after compiling) and there are no duplicates.

#4

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.

#5

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.

#6

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.

#7

Reminds me of the following:

0ja6uu2a8f701.jpg600x632 26.8 KB

#8

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.

#9

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!

#10

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.