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

On Fri, Jan 20, 2012 at 1:57 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:

On Fri, Jan 20, 2012 at 1:44 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:

Hi Henrik,


On Fri, Jan 20, 2012 at 10:33 AM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:

Hi,

this is a kind request for the BioC team to have another look at
fixing the binary affxparser builds. ?Quite a few OSX users on R
v2.14.0 have R crashing because of this problem.

Thanks for the prompt and the detailed problem report.

Since thread 'Re: [Bioc-devel] affxparser: Core dump with R 2.14.0 on
OSX' on Nov 7, 2011
[https://stat.ethz.ch/pipermail/bioc-devel/2011-November/002969.html]
became cluttered with mistakes, I'm starting a new thread on the same
topic.

PROBLEM:
The binary build of affxparser v1.26.2 for OSX provided by
Bioconductor is broken and causes R v2.14.0 to crash ("core dump",
"abort trap", ...) on OSX 10.6 ("Snow Leopard") and (I assume; someone
please confirm) OSX 10.7 ("Lion"),

I can confirm that it happens on Lion too.

but not OSX 10.5 ("Leopard"). ?A
reproducible example is:

library("affxparser");
readCdfHeader("Mapping10K_Xba142.cdf");

which should return a named header. (Download CDF file:
http://www.aroma-project.org/data/annotationData/chipTypes/Mapping10K_Xba142/Mapping10K_Xba142.CDF.gz
; 2.2Mb). ?Another example is
[http://www.aroma-project.org/data/annotationData/chipTypes/Mapping250K_Nsp/Mapping250K_Nsp.cdf.gz]:

library("affxparser");
readCdfHeader("Mapping250K_Nsp.cdf");


CURRENT WORKAROUNDS:
- Install affxparser from source
[http://bioconductor.org/packages/2.9/bioc/src/contrib/affxparser_1.26.2.tar.gz].
- Install Kasper Hansen's binary build (not universal?)
[http://www.braju.com/R/repos/osx_10.6/affxparser_1.26.2.tgz] that
works on (at least) OSX 10.6.8.

See also aroma.affymetrix thread 'OSX 10.6 & 10.7 users: Workaround
for faulty BioC build of affxparser v1.26.2' on Jan 14, 2012
[https://groups.google.com/forum/#!topic/aroma-affymetrix/lEfDanThLEA/discussion]


TROUBLESHOOTING:
I can confirm that installing from source, works on an OSX 10.6.8
machine with R v2.14.1
(http://cran.r-project.org/bin/macosx/R-2.14.1.pkg). ?Installing
Kasper's binary build also works. ?I've a limited understanding on the
different types of OSX package binaries, only access to OSX 10.6.8,
making it hard for me to do any more troubleshooting, but as far as I
understand there is something wrong with the way affxparser is build
on the Bioconductor servers.

An important fact to bear in mind is that the BioC Mac build servers
are running Leopard (OS X 10.5.8).

It's a bit tricky to debug since it works fine on the platform it's
built on...but using primitive means (Rprintf() statements), I was
able to narrow down the problem to the
FileHeaderReader::ReadMagicNumber()
function in
affxparser/src/fusion_sdk/calvin_files/parsers/src/FileHeaderReader.cpp

In that function, the expression
if (fileMagicNumber != DATA_FILE_MAGIC_NUMBER)
evaluates to true, and therefore an
affymetrix_calvin_exceptions::InvalidFileTypeException is thrown.

I don't really know why the magic number is wrong, or would vary
between operating systems, but perhaps this gives you something to go
on?

BTW, the trace is:
R: readCdfHeader()
C++:
R_affx_get_cdf_file_header()
FusionCDFData::ReadHeader()
FusionCDFData::CreateObject()
FusionCDFData::IsCalvinCompatibleFile()
GenericFileReader::ReadFileHeaderNoDataGroupHeader()
FileHeaderReader::Read()
FileHeaderReader::ReadMagicNumber()

Hope this helps. If I can be of assistance in further debugging this,
please let me know.

I should also have mentioned that in the ReadMagicNumber() function,
fileMagicNumber == 67
with the file Mapping10K_Xba142.cdf, and the expected magic number is 59.

Sorry for all the emails, but here's one more piece of info:
If I run the package with the debug statements on pitt, our Leopard
build machine, it works fine, as expected, but it also reports that
fileMagicNumber is 67. So the exception is still thrown, but execution
continues.

Whereas on my Lion machine, execution ends (after a pause) with "Abort trap: 6".
So I am not sure whether this exception is really part of the problem,
or just a red herring.

Hope this is helpful....
Dan

Dan

Thanks,
Dan

Thanks

Henrik