<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/11/2014 05:10 AM, Jakub Jelinek
<pre wrap="">On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:
<pre wrap="">On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:
<pre wrap="">On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
<pre wrap="">To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
Which is this in case anyone else was wondering:
Enable AddressSanitizer, a fast memory error detector. Memory
access instructions will be instrumented to detect out-of-bounds
and use-after-free bugs. See
<a class="moz-txt-link-rfc2396E" href="http://code.google.com/p/address-sanitizer/"><http://code.google.com/p/address-sanitizer/></a> for more details.
The run-time behavior can be influenced using the 'ASAN_OPTIONS'
environment variable; see
<a class="moz-txt-link-rfc2396E" href="https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags"><https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags></a>
for a list of supported options.
Also in case anybody else wonders about gcc failing to recognize
these options, you'll need to add BuildRequires for these: libasan
for -fsanitize=address and libubsan for -fsanitize=undefined (and
similarly for leak and thread sanitizers )
Yeah. But, note that the sanitizers are meant primarily for development,
not for production, and especially -fsanitize=thread and to some extent
-fsanitize=address aren't completely cheap, so if you do that, please do
so temporarily and don't forget to disable it again for production.
FWIW, some liveCD like e.g. the Electronic Lab started failing
<pre>libtool-2.4.2-23.fc21.i686 requires gcc = 4.8.2</pre>