R is crashing

Question

R is crashing

daniel-adrian opened this issue 8 years ago · 13 comments

Hi Jon -- thanks in advance. I'm working with some fMRI data; that is, a time series of 3-dimensional volumes and would like to register each volume. But first, I'm having some basic problems with your package. For example, the code
library(RNiftyReg); s <- array(11:110, dim=c(10,10))+rnorm(100); t <- array(1:100, dim=c(10,10)) + rnorm(100); niftyreg(source=s, target=t, scope="rigid")
is causing the "Bomb Error" in RStudio.

Any help would be greatly appreciated.

Answer 1 · 2016-06-28T09:46:36.000Z

Hi Daniel,

I can't reproduce the problem. Could you let me know your platform, and R and RNiftyReg versions, please?

Thanks.

Answer 2 · 2016-06-28T17:39:05.000Z

Sure.
R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
Platform: Windows 8.1, R says x86_64-w64-mingw32/x64 (64-bit),
RNiftyReg Version: 2.3.0

Answer 3 · 2016-06-29T15:37:58.000Z

Here's my real issue though: I'm trying to perform registration with the source and target 96x96x10 volumes at http://facweb.gvsu.edu/adriand1/images.RData. It works if I run

out <- niftyreg(source=source, target=target, scope="rigid")
without specifying the voxel dimensions, but if I specify
pixdim(target) <- c(2.5,2.5,4); pixdim(source) <- c(2.5,2.5,4)
and then run
out <- niftyreg(source=source, target=target, scope="rigid")
I get the error
[NiftyReg ERROR] Function: initialise_block_matching_method()
[NiftyReg ERROR] There are no active blocks
Error in niftyreg.linear(source, target, scope, init, sourceMask, targetMask, :
[NiftyReg] Fatal error with code 1

Thanks again. Also, other dimensions such as
pixdim(target) <- c(2,2,2); pixdim(source) <-c(2,2,2)``
crash R with the bomb error.

Answer 4 · 2016-06-30T11:12:17.000Z

OK, thanks for the additional details. This latter problem I can reproduce, and I've pushed commit 775ffbf to fix it. We've also tried it on Windows and the fix seems to resolve the other issue too.

Are you able to update your installation and try it? The easiest route is devtools::install_github("jonclayden/RNiftyReg"), as long as you have the Windows package-building toolchain.

Answer 5 · 2016-06-30T19:06:12.000Z

Thanks for the effort, but unfortunately I am seeing no change after I run devtools::install_github("jonclayden/RNiftyReg")

Answer 6 · 2016-06-30T19:18:04.000Z

You'll need to restart R to pick up the updated package. Did you try that?

Answer 7 · 2016-06-30T23:10:18.000Z

Thanks again. The second issue works now in the RGui but not in RStudio. Does RStudio not "restart" itself when you close it? The first issue is still leading to a crash in both places though.

Answer 8 · 2016-07-01T01:06:15.000Z

Another issue: my outputted images, which contain 10 slices, are all NAs for the first and tenth slice. Is it is possible for a rigid body registration to behave this way?

Answer 9 · 2016-07-01T01:41:15.000Z

But I didn't get any NAs when I used pixdim=c(1,1,1)

Answer 10 · 2016-07-01T10:40:44.000Z

OK, thanks. Restarting RStudio should be sufficient, so it's very odd that the crash happens in one front-end but not the other—assuming they're using the same package library. The problem is that we can no longer recreate the crash, which makes debugging it much harder. My laptop dual-boots Windows, but is currently being repaired, so I'll investigate further on that when I get it back. In the meantime I'll look into the NA issue, since it may well be related.

Answer 11 · 2016-07-01T14:54:23.000Z

Thanks very much! Also, to clarify, when I said I didn't get any NAs when I used pixdim=c(1,1,1), that was under the old package. Under the new package, I get the same amount of NAs for pixdim=c(1,1,1) and pixdim=c(2.5,2.5,4).

Answer 12 · 2016-07-06T13:17:20.000Z

Right, the problem with the NAs appears to be an upstream issue, since it also occurs when using the NiftyReg command-line programs. I've therefore asked the NiftyReg developers about it, and am waiting to hear back. In the meantime it seems to be possible to work around it by reapplying the transform to the source image, viz. applyTransform(forward(out), source). Unfortunately I don't yet know in what circumstances this will be necessary; sorry for the inconvenience.

Meanwhile the crashes are proving very hard to track down. By and large I can only reproduce them when a debugger is not attached to the process, and when I can catch them I can't get any meaningful information about which part of the code causes the crash. That leaves me with no real way of tracking it down. So I'm going to wait to hear about the other issue from the NiftyReg developers for now, and hope that they're connected!

Answer 13 · 2016-07-08T05:03:04.000Z

Thanks for your all of your help. It's doing what I need now.