Skip to content
Prev 9714 / 21307 Next

[Bioc-devel] msPurity build fail on Mac OS X (morelia)

On 09/20/2016 05:18 AM, Thomas Lawson wrote:
Hi Tom --

This might be fun!

You can see from

 
http://bioconductor.org/checkResults/3.4/bioc-LATEST/morelia-R-instpkgs.html

(linked from 
http://bioconductor.org/checkResults/3.4/bioc-LATEST/index.html '1633' 
installed packages) that in fact msPurityData is installed. Also, 
segfaults are rarely the result of missing packages. Instead, it is 
likely due to errors in C code of one sort or another. On my linux, I 
made sure I was using the 'devel' version of Bioconductor, and that all 
of my packages were up-to-date via biocLite(). I then checked out 
msPurity from svn, changed into the msPurity directory and installed it

     R CMD INSTALL .

then I changed to the vignettes directory, Stangled the source code

    cd vignettes
    R CMD Stangle msPurity-vignette.Rmd

(by the way, the products of build the package / vignette, 
msPurity-vignette.R should not be in svn).

I then ran the vignette under valgrind

     msPurity/vignettes$ R -d valgrind -f msPurity-vignette.R

leading to

 > pa <- purityA(msmsPths)
==19611== Mismatched free() / delete / delete []
==19611==    at 0x4C2EDEB: free (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19611==    by 0x11296DA5: cRamp::cRamp(char const*, bool) (cramp.cpp:98)
==19611==    by 0x1129FC87: RcppRamp::open(char const*, bool) 
(RcppRamp.cpp:23)
==19611==    by 0x112B49C4: Rcpp::CppMethod2<RcppRamp, void, char 
const*, bool>::operator()(RcppRamp*, SEXPREC**) 
(Module_generated_CppMethod.h:215)
==19611==    by 0x112B0FBF: 
Rcpp::class_<RcppRamp>::invoke_void(SEXPREC*, SEXPREC*, SEXPREC**, int) 
(class.h:212)
==19611==    by 0xED73CA0: CppMethod__invoke_void(SEXPREC*) (Module.cpp:200)
==19611==    by 0x4F0DFD0: do_External (dotcode.c:548)
==19611==    by 0x4F47F9E: Rf_eval (eval.c:713)
==19611==    by 0x4F4A6B7: do_begin (eval.c:1807)
==19611==    by 0x4F47D90: Rf_eval (eval.c:685)
==19611==    by 0x4F4964C: Rf_applyClosure (eval.c:1135)
==19611==    by 0x4F47B6C: Rf_eval (eval.c:732)
==19611==  Address 0x1b8a4220 is 0 bytes inside a block of size 400 alloc'd
==19611==    at 0x4C2E0EF: operator new(unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19611==    by 0x11296949: cRamp::do_ramp(long, eWhatToRead) 
(cramp.cpp:215)
==19611==    by 0x11296D9D: cRamp::cRamp(char const*, bool) (cramp.cpp:97)
==19611==    by 0x1129FC87: RcppRamp::open(char const*, bool) 
(RcppRamp.cpp:23)
==19611==    by 0x112B49C4: Rcpp::CppMethod2<RcppRamp, void, char 
const*, bool>::operator()(RcppRamp*, SEXPREC**) 
(Module_generated_CppMethod.h:215)
==19611==    by 0x112B0FBF: 
Rcpp::class_<RcppRamp>::invoke_void(SEXPREC*, SEXPREC*, SEXPREC**, int) 
(class.h:212)
==19611==    by 0xED73CA0: CppMethod__invoke_void(SEXPREC*) (Module.cpp:200)
==19611==    by 0x4F0DFD0: do_External (dotcode.c:548)
==19611==    by 0x4F47F9E: Rf_eval (eval.c:713)
==19611==    by 0x4F4A6B7: do_begin (eval.c:1807)
==19611==    by 0x4F47D90: Rf_eval (eval.c:685)
==19611==    by 0x4F4964C: Rf_applyClosure (eval.c:1135)
==19611==

which from 
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.rudefn means 
that memory allocated with new[] is being deallocated with free (rather 
than delete / delete[]

Remarkably, this change to mzR removes this particular valgind problem

Index: src/cramp.cpp
===================================================================
--- src/cramp.cpp	(revision 121179)
+++ src/cramp.cpp	(working copy)
@@ -95,7 +95,7 @@
          //      if (m_runInfo->m_data.scanCount < 0) { // undeclared 
scan count
          // this will provoke reading of index, which sets scan count
          rampScanInfo* tmp = getScanHeaderInfo ( 1 );
-        free(tmp);
+        delete(tmp);
          // }
          // END HENRY
      }

but doesn't get us out of the woods -- valgrind now complains

 >
 > xset <- xcms::xcmsSet(msmsPths)

vex: the `impossible' happened:
    isZeroU
vex storage: T total 3029292920 bytes allocated
vex storage: P total 640 bytes allocated

valgrind: the 'impossible' happened:
    LibVEX called failure_exit().

host stacktrace:
==20822==    at 0x38083F48: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==20822==    by 0x38084064: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
...
sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 20822)
==20822==    at 0x25A294E0: ??? (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x25A086FF: EC_POINT_mul (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0xB67335F: ???
==20822==    by 0xCF7F76F: ???
==20822==    by 0x5EB461A205EFD6FF: ???
==20822==    by 0xC221D2F: ???
==20822==    by 0x25A10E47: EC_KEY_check_key (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x25A11260: EC_KEY_set_public_key_affine_coordinates (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x25ACA882: ??? (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x25AC637F: ??? (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x25AC5A33: ??? (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x2599970C: FIPS_mode_set (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x25995F89: OPENSSL_init_library (in 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20822==    by 0x40104E9: call_init.part.0 (dl-init.c:72)
==20822==    by 0x40105FA: call_init (dl-init.c:30)
==20822==    by 0x40105FA: _dl_init (dl-init.c:120)
==20822==    by 0x4015711: dl_open_worker (dl-open.c:575)
==20822==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==20822==    by 0x4014BD8: _dl_open (dl-open.c:660)
==20822==    by 0x6C80F08: dlopen_doit (dlopen.c:66)
==20822==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==20822==    by 0x6C81570: _dlerror_run (dlerror.c:163)
==20822==    by 0x6C80FA0: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==20822==    by 0x4EA93F0: AddDLL (Rdynload.c:537)
==20822==    by 0x4EA996B: R_moduleCdynload (Rdynload.c:917)
==20822==    by 0x4F68979: internet_Init (internet.c:79)
==20822==    by 0x4F68AF2: R_newsock (internet.c:115)
==20822==    by 0x4EF39C0: do_sockconn (connections.c:3196)
==20822==    by 0x4F3B587: bcEval (eval.c:5658)
...

which frankly is too cryptic for me -- it seems perhaps like a call 
opening a socket connection is going wrong, but I really don't know if 
that is cause or effect, or even relevant to your problem.

The bottom line is that this is likely a problem in the C code of one of 
the packages that you are using.

Do you or a colleague have the expertise to work through this?

Martin
This email message may contain legally privileged and/or...{{dropped:2}}