[Bioc-devel] R CMD check without WARNING: g++ and STL issue for xcms and mzR

Hi,

just a quick report, I followed this up to r-devel,
and a fix adding -O2 back to default CXXFLAGS
has been committed (r72549, see [1]) to R by Martyn Plummer,
thus "fixing" the abort() related WARNING in mzR/xcms
once this gets into the R version used on malbec2.

Yours,
Steffen

[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.org_R-5Fsvnlog-5F2013&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=nRu69QAXHm0lBKf9Al-8KvSvfGAqLrzp1uWirvd6XF0&e=

On Mi, 2017-04-12 at 22:07 -0400, Martin Morgan wrote:

On 04/12/2017 11:31 AM, Neumann, Steffen wrote:

Hi,

certainly these are good suggestions, but I would tend
to simply add some whitelisting functionality if the
cause is beyond the package's control.

In this case I doubt it is a handler for SIGABRT,
since that would not go away with -O2, or would it ?

For now, just adding -O2 on Linux would fix this issue.

The code is compiled on the user machine, so twiddling with the
build
system masks the problem from the developer while leaving the user
vulnerable.

Calling abort() is certainly a serious problem, abruptly ending the
user
session.

Optimization could either eliminate a dead code path, or it could
compile the call to abort in a way that R no longer recognizes it --
R
is doing the equivalent of nm *.o |grep abort.

It would be appropriate to ignore the warning about abort() if it
were
never reached; one would only know this by careful code analysis
rather
than adjusting optimization flags.

Rsamtools re-defines abort (before including offending headers), and
avoids the warning (and crash), with the equivalent of

   PKG_CFLAGS=-D__builtin_abort=_samtools_abort

where _samtools_abort is my own implementation to signal an R error
telling the user that an unrecoverable error has occurred and they
should stop what they are doing. Unfortunately this requires
-U_FORTIFY_SOURCE and doesn't actually address the reason for the
abort,
and is hardly ideal.

I don't think the developer can set the optimization flag in a way
that
overrides the R or user setting (the PKG_CXXFLAGS is inserted before
the
R flags). And it doesn't address the underlying problem anyway.

Kasper's pragmatic approach (it's a very unlikely situation, and
difficult to fix, so live with the warning) seems like it would often
be
a reasonable one.

FWIW this little bit of C++ seems to be enough to include abort

tmp.cpp:
-------
#include <list>

int foo(int argc, const char *argv[]) {
     std::list<int> l1, l2;
     std::list<int>::iterator it;

     it = l1.begin();
     l1.splice (it, l2); // mylist1: 1 10 20 30 2 3 4

     return 0;
}
-------

Test with

   rm -f tmp.o && R CMD SHLIB tmp.cpp && nm tmp.o | grep abort

with compiler settings in

~/.R/Makevars
-------------
CXXFLAGS = -g -O0
-------------


Martin

Yours,
Steffen


On Mi, 2017-04-12 at 10:07 -0400, Vincent Carey wrote:

Suppose you had a handler for SIGABRT in your code.  Could CMD
check
check for that and, if found, refrain from warning?  That is
somewhat
involved and goes beyond Bioc but it seems a principled way of
dealing with operations in binary infrastructure whose behavior
we
cannot control.  The problem will surely arise in other settings.
Could BiocCheck prototype the approach?

On Wed, Apr 12, 2017 at 9:12 AM, Kasper Daniel Hansen
<kasperdanielha
nsen at gmail.com> wrote:

I think "we" have to appreciate that the warning about
abort/etc
and others
is really hard to deal with when you're including (large)
external
source
as you do in mzR and for example affxparser /
Rgraphviz.  Generally
fixing
those in external code requires a lot of effort, and the
further
effort to
document that the included sources in the package are different
from the
official sources.  I have had warnings about this in affxparser
for
a long,
long time and no-one has bothered me over it.

What might be nice is (somehow) setting a flag saying this
should
be
ignored in the check process, but of course we don't want that
flag
to be
set by the developer, because usually, these issues should be
dealt
with.
So perhaps there is nothing to do and I always have to click on
each build
report to verify that there is only 1 warning from this issues
and
not
others.

Best,
Kasper

On Wed, Apr 12, 2017 at 7:22 AM, Neumann, Steffen <sneumann at ipb
-hal
le.de>
wrote:

Hi Martin and malbec2 admin(s):

Some more digging revealed that malbec2
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2D&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=kUGjYuMkhD3e-WsuG6IAuE_MTjPtNkrZw9B4I-9xpwM&e=
LATEST/malbec2-NodeInfo.html
is using "CFLAGS=-g -O2 -Wall" but only "CXXFLAGS=-Wall"
while e.g. tokay2 uses "CXXFLAGS=-O2 -Wall -mtune=core2"

The -O2 optimisation is getting rid of the abort() symbol,
as shown in https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sneumann_xcms_issues_150-23&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=Bzp4j1sYGGHCblnhv2xferniQzw1BPE-wmoHi0zWSLM&e=
issuecomment-293545521

=> Is there a way to get -O2 back on the BioC build machines
?
    This should fix our WARNING. Bonus: will fix the same
issue
in

mzR :-)

Yours,
Steffen

On So, 2017-04-02 at 10:01 -0400, Martin Morgan wrote:

On 04/02/2017 06:52 AM, Neumann, Steffen wrote:

[...]
in preparation for the release, we are hunting down
WARNINGS
"Found ?abort?, possibly from ?abort? (C)" in xcms/mzR.
The abort() call is not coming from XCMS, but rather
from the C++ code in the STL, and we have no idea

[...]

We are tracking this in:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sneumann_xcms_issues_150&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=RJrwRqEKnRJOw5M0FS7za46JPhrG2vKflu80XCWzxVI&e=

[...]

I don't think Bioconductor can help with this; maybe the
Rcpp

or R-

devel mailing lists?

--
3rd Leibniz Plant Biochemistry Symposium, 22.-23. of June
2017
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ipb-2Dhalle.de_en_public-2Drelations_3rd-2Dleibniz-2Dplant&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=JV-QoY63QkPHNGmis61NuX2JS_4rxBN6c7oFCQFGvm8&e=
-bio

chemis

try-symposium/
--
IPB Halle                    AG Massenspektrometrie &
Bioinformatik
Dr. Steffen Neumann          https://urldefense.proofpoint.com/v2/url?u=http-3A__www.IPB-2DHalle.DE&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=tW4jM8Um0HwJ4_bkERUrB4C0DfUfjiz0ikU8_6I5Dho&e=
Weinberg 3                   Tel. +49 (0) 345 5582 - 1470
06120 Halle                       +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

--
3rd Leibniz Plant Biochemistry Symposium, 22.-23. of June
2017
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ipb-2Dhalle.de_en_public-2Drelations_3rd-2Dleibniz-2Dplant&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=JV-QoY63QkPHNGmis61NuX2JS_4rxBN6c7oFCQFGvm8&e=
-bio

chemis

try-symposium/
--
IPB Halle                    AG Massenspektrometrie &
Bioinformatik
Dr. Steffen Neumann          https://urldefense.proofpoint.com/v2/url?u=http-3A__www.IPB-2DHalle.DE&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg&s=tW4jM8Um0HwJ4_bkERUrB4C0DfUfjiz0ikU8_6I5Dho&e=
Weinberg 3                   Tel. +49 (0) 345 5582 - 1470
06120 Halle                       +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

        [[alternative HTML version deleted]]

This email message may contain legally privileged and/or confidential
information.  If you are not the intended recipient(s), or the
employee or agent responsible for the delivery of this message to the
intended recipient(s), you are hereby notified that any disclosure,
copying, distribution, or use of this email message is
prohibited.  If you have received this message in error, please
notify the sender immediately by e-mail and delete this email message
from your computer. Thank you.