does segfault mean (always) a bug?
It looks like a problem in the Matrix package. 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) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base 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' Traceback: 1: EK %*% E 2: EK %*% E Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: Bill Dunlap TIBCO Software wdunlap tibco.com 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
______________________________________________ R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.