[R] does segfault mean (always) a bug?

[Martin Maechler]

>>>>> William Dunlap <wdunlap at tibco.com>
>>>>>     on Wed, 6 May 2015 09:53:50 -0700 writes:

    > It looks like a problem in the Matrix package.  
Indeed.

Thanks to Bill Dunlap for the diagnostics below (and other
offline information and) I have been able to fix the bug
yesterday in the R-forge version of Matrix.
The problem was due to using a version of memory allocation
which is known to be quite fast... but is not to be used for
large objects .. which we have here.

I plan to release the amended version of Matrix to CRAN as 

  Matrix_1.2-1  

rather sooner than later.

With thanks to Bill and Pavel,
Martin Maechler
ETH Zurich

    > I made the file KE.rda containing the Matrix objects K and
    > E constructed in calc.diffusion.kernel by adding a save()
    > call just before where R dies in the original example:

    > K = lam$values[1] * I - M
    > E = I - matrix(1, ncol = ncol(I), nrow = nrow(I))/ncol(I)
    > cat("saving K, E, etc. in /tmp/KE.rda\n")
    > save(K, E, deg, invD, I, W, M, lam, file="/tmp/KE.rda")
    > cat("    done making the file\n")
    > K = E %*% K %*% E

    > With that file in place I get
    >> library(Matrix)
    >> load("KE.rda")
    >> sessionInfo()
    > R version 3.2.0 (2015-04-16)
    > Platform: x86_64-unknown-linux-gnu (64-bit)
    > Running under: Ubuntu precise (12.04.5 LTS)

    [ .......... ]

    > other attached packages:
    > [1] Matrix_1.2-0

    > loaded via a namespace (and not attached):
    > [1] grid_3.2.0      lattice_0.20-31
    >> str(E)
    > Formal class 'dsyMatrix' [package "Matrix"] with 5 slots
    > ..@ x       : num [1:143376676] 1.00 -8.35e-05 -8.35e-05 -8.35e-05
    > -8.35e-05 ...
    > ..@ Dim     : int [1:2] 11974 11974
    > ..@ Dimnames:List of 2
    > .. ..$ : NULL
    > .. ..$ : NULL
    > ..@ uplo    : chr "U"
    > ..@ factors : list()
    >> str(K)
    > Formal class 'dgCMatrix' [package "Matrix"] with 6 slots
    > ..@ i       : int [1:487692] 0 69 948 951 1027 1192 1414 1420 1421 1714
    > ...
    > ..@ p       : int [1:11975] 0 27 125 147 199 212 221 230 254 274 ...
    > ..@ Dim     : int [1:2] 11974 11974
    > ..@ Dimnames:List of 2
    > .. ..$ : chr [1:11974] "GO:0000002" "GO:0000003" "GO:0000012"
    > "GO:0000018" ...
    > .. ..$ : chr [1:11974] "GO:0000002" "GO:0000003" "GO:0000012"
    > "GO:0000018" ...
    > ..@ x       : num [1:487692] 32.2163 -0.004674 -0.000722 -0.005316
    > -0.014022 ...
    > ..@ factors : list()
    >> EK <- E %*% K
    >> EKE <- EK %*% E

    > *** caught segfault ***
    > address 0x7fffa7e1ccf8, cause 'memory not mapped'

    [...............]

    > On Wed, May 6, 2015 at 1:57 AM, Martin Maechler <
    > maechler at lynne.stat.math.ethz.ch> wrote:

    >> >>>>> lejeczek  <peljasz at yahoo.co.uk>
    >> >>>>>     on Wed, 6 May 2015 08:20:46 +0100 writes:
    >> 
    >> > On 05/05/15 20:36, Duncan Murdoch wrote:
    >> >> On 05/05/2015 2:54 PM, lejeczek wrote:
    >> >>> hi eveybody
    >> >>>
    >> >>> I'm trying something simple (Biocunductor packages), so
    >> >>> simple I believe it's example from docs but I get segfault.
    >> >>> I don't suppose incorrect scripting can cause segfault, right?
    >> >> In R, a segfault always indicates a bug.  What's not so clear is
    >> whether
    >> >> it is a bug in R, a bug in a contributed package, or a bug in some
    >> >> underlying system library.
    >> >>
    >> >> If you can only trigger the bug when using a Bioconductor package,
    >> then
    >> >> the first guess is that it is that package, and the maintainer of
    >> that
    >> >> package is in the best position to track it down further.  If you
    >> can
    >> >> simplify the code to trigger it without using any contributed
    >> packages,
    >> >> then it could well be a bug in R, and we'd like to see code to
    >> reproduce it.
    >> >>
    >> >> Duncan Murdoch
    >> >>
    >> > hi Duncan
    >> > I remember that this was a principle of most of programming
    >> > languages, only a bug in the code and/or compiler could
    >> > cause segfault.
    >> > In my case it is a contributed package, specifically GOSim
    >> > package, I'm not R programmer and I realise my scripting is
    >> > far from good and possibly with errors.
    >> > I could send that snippet of the code here if people think
    >> > it can be looked into and segfault could be replicated?
    >> > I also emailed the author.
    >> 
    >> > many thanks
    >> > P.
    >> 
    >> Dear P.,
    >> 
    >> in the case of segfault from using a contributed package,
    >> you should typically really only email the package maintainer
    >> (which may different than the package authors), and not R-help.
    >> Only if the maintainer does not respond at all (and only if the
    >> package is open source, typically CRAN) should you ask for help here
    >> or another public forum.
    >> 
    >> (I would also think it to be polite to the maintainer who has
    >> volunteered her/his code to be used by you if you give him an
    >> opportunity to see, comment and fix the problem)
    >> 
    >> Martin Maechler
    >> ETH Zurich