Dear Hervé and Martin, It seems the above problem on the Windows builds has been resolved for some time now. However, any updates on Linux in the release branch are not taking effect since some/all of the Openbabel dependencies are not available on the corresponding Linux build system (here Ubuntu 18.04). However, Ubuntu 20.04 seems to be fine but may not be used to create the source download instance at the moment? As a result, the package is only up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not Linux (still at ChemmineOB_1.28.0.tar.gz): http://bioconductor.org/packages/release/bioc/html/ChemmineOB.html. To fix this, one suggestion would be whether the functional build from the 20.04 system could be pushed instead of 18.04? Not sure whether this is less effort than installing the dependencies on 18.04 that may be discontinued soon - just a suggestion/question?
On the development branch the situation is opposite where the dependencies are missing on Windows and OSX but Linux is fine: http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineOB/. We realize that the dependencies of the ChemmineOB package creates extra workload for the Bioc team, and we are extremely grateful for the support by the Bioc core team. Please let us know if there is anything on our end that could be done to resolve this and/or to minimize your workload as much as possible. Thanks, Thomas On Mon, Feb 8, 2021 at 10:02 AM Martin Morgan <mtmorgan.b...@gmail.com> wrote: > It's likely failing because your package has C source code that accesses > memory in an invalid way. Likely the bug is present on all platforms, but > only apparent, for the tests you have written, on Windows. The right thing > to do is to fix the bug, rather than avoid by not running on the > troublesome platform. > > Under Linux you'd likely have success with valgrind or UBSAN; if you were > reasonably confident that the package occurred in unit tests, and you have > a script to run the unit tests run_tests.R then something like > > R -d valgrind -f run_tests.R > > may be productive. valgrind is slow so it pays to narrow the problem down > as much as possible. > > Maartin > > On 2/8/21, 12:43 PM, "Bioc-devel on behalf of Kevin Horan" < > bioc-devel-boun...@r-project.org on behalf of kho...@cs.ucr.edu> wrote: > > > I have a package which randomly segfaults when running my unit > tests only on windows i386, but never on x64, or any other OS. I can't > imagine there are many out there still running i386 systems are there? > Is it possible to just disable the i386 build on bioconductor so that > the tests are not run on that architecture? > > I have of course done my best to debug the issue, but all I get > is > an error in some nt dll file, with no useful message or location. I'm > I > Linux guy, I don't know how to do the in-depth debugging that would be > required to track this bug down on windows. I tried disabling each > test > one by one to see which one caused the crash, but as is typical with > segfaults, changing the setup can mask the bug even when the bad code > is > still be executed. Each test runs fine in isolation. > > Thanks > > Kevin > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- Thomas Girke, Ph.D. Professor of Bioinformatics 1207F Genomics Building University of California Riverside, CA 92521 E-mail: thomas.gi...@ucr.edu URL: https://girke.bioinformatics.ucr.edu Phone/Cell/Text: 951-732-7072 Fax: 951-827-4437 [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
