xcms
xcms copied to clipboard
sneumann
Build error on macOS on BioC
Hi, we are currently getting on http://bioconductor.org/checkResults/devel/bioc-LATEST/xcms/merida1-buildsrc.html
--- re-building ‘xcms-lcms-ms.Rmd’ using rmarkdown
Sizes of mz and intensity arrays don't match.
Quitting from lines 103-106 (xcms-lcms-ms.Rmd)
Error: processing vignette 'xcms-lcms-ms.Rmd' failed with diagnostics:
dims [product 864] do not match the length of object [432]
--- failed re-building ‘xcms-lcms-ms.Rmd’
interestingly, 864=432*2. Yours, Steffen
Can not reproduce on the official R release (i.e. the binary version provided by R):
R version 3.6.1 (2019-07-05)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib
Also checked with the very latest MSnbase (2.11.13) which was pushed to day to bioc: all OK. I hope this was some temporary problem.
While the issue was previously kinda self-healing, we have that again:
--- re-building ‘xcms-lcms-ms.Rmd’ using rmarkdown
Sizes of mz and intensity arrays don't match.
Quitting from lines 103-106 (xcms-lcms-ms.Rmd)
Error: processing vignette 'xcms-lcms-ms.Rmd' failed with diagnostics:
dims [product 864] do not match the length of object [432]
--- failed re-building ‘xcms-lcms-ms.Rmd’
The code snippet where this happens is
cwp <- CentWaveParam(snthresh = 5, noise = 100, ppm = 10,
peakwidth = c(3, 30))
dda_data <- findChromPeaks(dda_data, param = cwp)
Hence we need to keep an eye out, although no urgent actions are needed. Nevertheless, um, interesting. Yours, Steffen
Martin Morgan suggested:
Errors that are intermittent and platform-specific are often due to memory corruption, and can be investigated on Linux platforms with valgrind or similar tools. Have you taken this approach?
Hi @jorainer, could you add instructions on your mostly reproducible example here, so that others on macOS can check if that also occurs on their setup ? I know @korseby would be able to check.
Those of you reading this on macOS, could you please check and report back including information on your macOS version, LLVM compiler version and R sessionInfo() ?
Thanks in advance, Yours, Steffen
replicating the error is pretty tricky - also because at present I get it on files that I'm not allowed to share...
but a small update in between: I was able to run R with a debugger attached and luckily (?) I got a segfault - but can't really do anything with the output from the debugger:
Process 19476 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff203778bd libsystem_platform.dylib`_platform_memchr$VARIANT$Haswell + 29
libsystem_platform.dylib`_platform_memchr$VARIANT$Haswell:
-> 0x7fff203778bd <+29>: vpcmpeqb (%rdi), %ymm0, %ymm1
0x7fff203778c1 <+33>: vpcmpeqb 0x20(%rdi), %ymm0, %ymm2
0x7fff203778c6 <+38>: vpmovmskb %ymm1, %eax
0x7fff203778ca <+42>: vpmovmskb %ymm2, %esi
Target 0: (R) stopped.
anybody any ideas on that? or what I could do to dig deeper into it?
Info on my setup: I'm running the R installed through homebrew - it's not the official R version, but that one has the problem that I can't assign/link a debugger to it. Anyway, the I got the same error also with the official R.
My session info:
> sessionInfo()
R version 4.1.1 (2021-08-10)
Platform: x86_64-apple-darwin20.6.0 (64-bit)
Running under: macOS Big Sur 11.6
Matrix products: default
BLAS: /usr/local/Cellar/openblas/0.3.18/lib/libopenblasp-r0.3.18.dylib
LAPACK: /usr/local/Cellar/r/4.1.1_1/lib/R/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.1
The llvm/clang version:
~ ❯❯❯ clang --version ✘ 127
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
@jorainer There is a problem with the linker. It is probably "just" a mismatch between version of XCode and clang in /usr/bin. I had trouble like this numerous times before as every time xcode is updated, the commandline tools are not for some reason.
Can you try to reinstall the commandline tools as described here? https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
That's how clang is reporting on my machine (Big Sur 11.6, Xcode 13):
/usr/bin/clang
[kristian@funkel ~]$ clang --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin```
@korseby , you suggest then to install again the command line tools (no idea why it's not being updated...) and then re-install R and try again?
Yes, reinstall the latest version of the CLT, remove all intermediary build files of R and try to reinstall R again. Worked for me for pytorch the last time.
Hm, didn't help unfortunately:
f04870_Prot_04_F04.mzML
Process 67730 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1a7717a28)
frame #0: 0x000000019898dd14 mzR.so`pwiz::msdata::id::translateNativeIDToScanNumber(pwiz::cv::CVID, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 260
mzR.so`pwiz::msdata::id::translateNativeIDToScanNumber:
-> 0x19898dd14 <+260>: movzbl (%r12), %edx
0x19898dd19 <+265>: testb $0x1, %dl
0x19898dd1c <+268>: je 0x19898dfbc ; <+940>
0x19898dd22 <+274>: movq 0x10(%r12), %rax
Target 0: (R) stopped.
The error is actually pretty interesting, because it comes from the pwiz code that tries to extract the scan index (integer) from the scan ID (a string).
Hm.... This error is related to mzR? Maybe rebuilding mzR would help or have you recompiled everything from scratch?
Note: I by chance could get rid of the initial error reported in this issue:
isMSnbaseFastLoad()
FALSE
for (i in 1:20) {
chr <- chromatogram(data)
}
Sizes of mz and intensity arrays don't match.
Error: BiocParallel errors
element index: 7, 8, 9, 10, 11, 12, ...
first error: BiocParallel errors
element index: 1
first error: dims [product 0] do not match the length of object [3775]
If I do the same with:
setMSnbaseFastLoad(TRUE)
for (i in 1:20) {
chr <- chromatogram(data)
}
Note: that is with the mzR with the updated proteowizard and on data which is a data set on which I got this error message recently. If fast load is TRUE then only the peaks data (spectra) are retrieved from the mzML file while with FALSE before calling mzR::peaks, mzR::header is called. Seems that, at least for this data set, the additional reading of the header makes problems. The fun fact is that I introduced this options to get rid of similar random errors on macOS. Also, this option is only enabled in macOS, on Linux and Windows it is by default FALSE.
First, the only thing I can think of is a version mismatch between your library installations. I had similar problems and a fresh install and/or MacOS upgrade helped. It could also be mixed header files of different versions of llvm and/or gcc. Hard to tell. These error messages are pretty much meaningless. Do you use homebrew or also other things like macports or fink to install packages?
Second, you really made my day! setMSnbaseFastLoad(TRUE) fixes all the problems I am getting on Mac since 2-3 years... Re-running my latest study in the background since morning and no errors so far!
Thanks for the feedback @korseby - means I will revert the default for macOS in MSnbase and Spectra (i.e. enable the fast load also on macOS).
I did further testing on setMSnbaseFastLoad(TRUE) and can confirm that peak detection and various xcms-MS2 code is working without errors now on MacOS.
Hi, On MacOS with M1 chip, setMSnbaseFastLoad(TRUE) will generate the errors. I test the code multiple times and sometimes it will pass without errors and it seems a random error.
Then I use setMSnbaseFastLoad(FALSE), the error disappeared. Since the default setting is TRUE, I just left this note here for users with the same issue.
In my case, mzR is complied with clang instead of gcc and I am using R 4.1.2, Apple silicon arm64 build.
Hi @yufree , thanks for reporting!
I can confirm that I get the same issues (again) with setMSnbaseFastLoad(TRUE) on macOS 12.1 Monterey. Setting setMSnbaseFastLoad(FALSE) fixes it again. This seems to be now a macOS-version-specific (maybe xcode dependent) thing...
I'm using the R from homebrew:
> sessionInfo()
R version 4.1.2 (2021-11-01)
Platform: x86_64-apple-darwin21.1.0 (64-bit)
Running under: macOS Monterey 12.1
Matrix products: default
BLAS: /usr/local/Cellar/openblas/0.3.19/lib/libopenblasp-r0.3.19.dylib
LAPACK: /usr/local/Cellar/r/4.1.2/lib/R/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.2