Skip to content

[Bioc-devel] affxparser: Core dump with R 2.14.x on OSX [take #2]

3 messages · Dan Tenenbaum

Original
Dan Tenenbaum
#
On Fri, Jan 20, 2012 at 3:20 PM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:
Yes. Or at least, I assume it is valid. But no other errors are displayed.

Here is what it displays:

$ncols
[1] 658

$nrows
[1] 658

$nunits
[1] 10208

$nqcunits
[1] 9

$refseq
[1] ""

$chiptype
[1] "Mapping10K_Xba142"

$filename
[1] "./Mapping10K_Xba142.CDF"

$rows
[1] 658

$cols
[1] 658

$probesets
[1] 10208

$qcprobesets
[1] 9

$reference
[1] ""
pitt is already running R 2.14.1, see:
http://bioconductor.org/checkResults/release/bioc-LATEST/pitt-NodeInfo.html
Sounds good, although we already tried this test, with another Leopard
machine we had, and the resulting package also crashed on newer OSes.
But it is probably still valuable to have someone else try this, and
if they create a package that works on newer OSes, then we can start
to look at differences in compilers, etc.

BTW, the last known 'good' version was built on pelham, here is the
node info for that machine:
http://bioconductor.org/checkResults/2.8/bioc-20111021/pelham-NodeInfo.html

It looks like the same versions of C and C++ compilers were used on both.
One difference is that R CMD config CXX on pelham is "g++-4.2 -arch
i386" whereas on pitt it is "g++ -arch i386", however, on pitt,
ls -l /usr/bin/g++
lrwxr-xr-x  1 root  wheel  7 Jun 29  2011 /usr/bin/g++ -> g++-4.2
so I guess they are really equivalent.
(The same is true of gfortran, if that matters.)

This makes me wonder if the "something" that "happened" could have
happened between R 2.13 and 2.14. Of course, the problem seems to be
deep inside C++ code that is not even using SEXPs, but it's possible
something could have changed in .Call()...

I'm in the process of doing further testing (trying to build my debug
version on Lion and seeing if the magic number mismatch occurs). Will
let you know what happens.
Dan
Dan Tenenbaum
#
On Fri, Jan 20, 2012 at 3:51 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:
A couple more data points:
If I build affxparser on Lion, the magic number mismatch still occurs,
but the R function call completes without error.

If I comment out the "throw" in FileHeaderReader::ReadMagicNumber(),
and build it on pitt, the same error occurs on Lion. So it doesn't
really matter, apparently, whether that exception is thrown, but that
function is as far as I am able to trace before the "abort trap".

FWIW,
Dan
Dan Tenenbaum
#
On Fri, Jan 20, 2012 at 4:43 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:
Looks like I spoke too soon on this.
If I comment out that throw, and then the one in
FileHeaderReader::ReadVersion(),
then the code continues but dies a bit more verbosely:

R(90579) malloc: *** mmap(size=18446744071864250368) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

 *** caught segfault ***
address 0x5, cause 'memory not mapped'

Traceback:
 1: .Call("R_affx_get_cdf_file_header", filename, PACKAGE = "affxparser")
 2: readCdfHeader("Mapping10K_Xba142.cdf")
aborting ...
Segmentation fault: 11

The exact place it seems to die is one of the first two lines of
std::string FileInput::ReadString8(std::ifstream &instr, int32_t len)
in FileInput.cpp.
It's a bit tricky to tell what is going on because I am limited to
printf statements. I put one before each line in this function:

        Rprintf("rs8b_0\n");
        char *buf = new char [len+1];
        Rprintf("rs8b_1\n");
        instr.read(buf, len);
        // and so on...

but the output is in an unexpected order:
[...]
rs8b_1
rs8b_0

At any rate, that is the last line of debug output before the segfault.

HTH,
Dan