>>>>> William Dunlap <wdun...@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 <
> maech...@lynne.stat.math.ethz.ch> wrote:
>> >>>>> lejeczek <pelj...@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@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.
