[Rd] stack overflow? was Re: [R] segfault in gplots::heatmap.2
Martin Morgan
mtmorgan at fhcrc.org
Thu Aug 30 21:39:43 CEST 2012
I think this belongs on R-devel and I'm forwarding there.
Here's a more refined example
library("XLConnect")
load(file="ddr.Rda")
oV <- function(x) {
if (is.leaf(x)) {
return(x)
}
for (j in seq_along(x)) {
b <- oV(x[[j]])
}
x
}
res <- oV(ddr) # segfault for me under 2.15.1
str(ddr) # segfault more reliably
'ddr' is a dendrogram produced from Andreas' original object at the
point where heatmap.2 calls 'reorder'. 'oV' is a reduced version of the
internal function in reorder.dendrogram.
Simple changes to oV above have interesting effects, e.g., removing {}
in the 'if' and 'for' mean that the segfault labelled at 2.15.1 does not
occur.
Under R-devel, valgrind complains about Java (I think this is a red
herring) and then
14604== Can't extend stack to 0x7fef03370 during signal delivery for
thread 1:
==14604== too small or bad protection modes
which likely indicates stack overflow.
gdb shows that we're several 1000's of calls down when the segfault occurs.
I think R overflows its stack, and that rJava just makes that more
likely to occur. I don't really know how to investigate a stack overflow
further.
Martin
R version 2.15.1 Patched (2012-08-26 r60438)
Platform: x86_64-unknown-linux-gnu (64-bit)
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=C 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
> sessionInfo()
R Under development (unstable) (2012-08-20 r60336)
Platform: x86_64-unknown-linux-gnu (64-bit)
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=C 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
On 08/30/2012 12:04 PM, R. Michael Weylandt wrote:
> On Thu, Aug 30, 2012 at 2:30 AM, Andreas Leha
> <andreas.leha at med.uni-goettingen.de> wrote:
>> Hi all,
>>
>> I experience a segfault when calling gplots::heatmap.2(), but only when
>> certain other packages are loaded.
>>
>> I am not sure for the correct place to send this bug report. Should I send
>> it to the package maintainers directly? If R-help is the wrong place,
>> please feel free to direct me to the correct one.
>>
>> I am on debian (testing) linux 64 with the binary R distribution
>> from the repositories (version 2.15.1).
>>
>> Below follows a simple reproducible example causing the segfault on my
>> machine.
>> The offending dataset is quite big, so instead of posting it here I put
>> it here: https://gist.github.com/3523761. Please put it into offending.txt to
>> make the code below working.
>>
>> This is the example. Note, that without loading 'XLConnect' this works
>> nicely.
>> #+begin_src R
>> library("gplots")
>> library("XLConnect") # any of XLConnect, venneuler, xlsx case a segfault
>>
>> offending <- dget("offending.txt")
>> heatmap.2(x=offending)
>> #+end_src
>>
>> Interestingly, I get a segfault when loading any of c("XLConnect",
>> "venneuler", "xlsx"), which all depend on rJava. But loading rJava on
>> its own did not produce a segfault.
>
> Hi Andreas,
>
> Thanks for the nicely reproducible example. Unfortunately, I can't
> reproduce the segfault on my Mac OS X 10.6 running R 2.15.0. I could
> only test with rJava + venneuler because xlsx and XLConnect fall
> victim to Mac's Java "infelicities." It's something of a formality,
> but are you sure you are up-to-date with your packages as well as with
> R itself. Something like
>
> update.packages(checkBuilt = TRUE)
>
> will ensure you've got the most current release of all your packages.
> (Note that I'm not sure that's the right way to do it on Debian)
>
> Do you happen to know if this happens with other versions of R? e.g.,
> 2.15.0 or the not-yet-released R-devel or R-patched (maintenance
> branch of 2.15.z which will become 2.15.2 eventually)
>
> Consequently, I'd suspect that there's something going on in the
> intersection of Java + R + Deb Testing, so three places you might seek
> more advanced help, as this is likely deeper than the day-to-day of
> this list. i) The rJava mailing list
> (http://mailman.rz.uni-augsburg.de/mailman/listinfo/stats-rosuda-devel);
> ii) the R-SIG-Debian list; iii) the R Devel list.
>
> I'm not sure which one makes the most sense to try, but I'd think the
> third should be of last resort, because it seems least likely to be a
> problem in base-R if it requires rJava being around to reproduce. The
> R-SIG-Debian list most likely has someone who can reproduce your exact
> config.
>
> Cheers,
> Michael
>
>>
>> Regards,
>> Andreas
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> 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.
>
> ______________________________________________
> R-help at r-project.org mailing list
> 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.
>
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddr.Rda.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20120830/21c615f1/attachment.tar>
More information about the R-devel
mailing list