UndefinedBehaviorSanitizer failed to deallocate
Thu Nov 5 00:37:00 GMT 2015
On 11/04/2015 01:39 AM, Mason wrote:
> On 04/11/2015 04:29, Martin Sebor wrote:
>> On 10/24/2015 07:47 AM, Alex Markin wrote:
>>> I don't know how to report this bug, but I have the following
>>> situation. I compile my program with "-fsanitize=undefined". My
>>> program is a compiler. After that I start compiling the 465.tonto
>>> SPEC. And while compiling it I get the following error:
>>> ==19735==ERROR: UndefinedBehaviorSanitizer failed to deallocate
>>> 0x100000 (1048576) bytes at address 0x7f25c1b00000
>>> ==19735==Sanitizer CHECK failed:
>>> (("unable to unmap" && 0)) != (0) (0, 0)
>>> My gcc is:
>>> x86_64-none-linux-gcc --version
>>> x86_64-none-linux-gcc (GCC) 6.0.0 20151018 (experimental)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>> my system is:
>>> $ uname -a
>>> Linux ubuntu64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
>>> (2015-04-24) x86_64 GNU/Linux
>>> This bug is reproducable with stable gcc-5 on debian system. To my
>>> pity I can't give you the binary or source of my compiler, but I can
>>> try to get information you need to fix this bug
>> Unless this is a known problem (my Bugzilla search for the strings
>> mentioned above didn't turn up anything), the information needed
>> to fix the problem is a standalone test case that reproduces it.
>> The full source code of your project isn't necessary (or even
>> desirable), just a test case reduced from the translation unit
>> on which GCC aborts with the error above.
> I believe you misread Alex's message.
> It's not gcc which aborts. It's the binary produced by gcc.
> IIUC, he has src.c which he compiles with
> gcc -fsanitize=undefined [other options?] src.c
> And then ./a.out [argument list] errors out in libsanitizer.
> The problem seems to be in libsanitizer.
> Creating an appropriate test-case might be tricky.
Thanks for the clarification. I misspoke when I said that GCC
aborts (it's clear from the ERROR that it's the sanitizer output
and not a GCC ICE). It's less clear (to me at least) whether the
problem is in the sanitizer or in the code emitted by GCC that
calls into it.
I agree that creating a test case may not be straightforward.
In these cases (of code generation problems), scripting the test
case reduction can be especially effective and save a lot of
time. The first step is to identify the miscompiled translation
unit (or units when LTO is used). This can be automated by doing
a binary search, alternately compiling with and without the
-fsanitize option and running the resulting program to see when
it goes away. With the problem translation units identified,
the next step is to remove the remaining translation units while
replacing the symbols defined in them that are used with dummies
so they can still be referenced or called. IME, this is a manual
process and can be quite tedious because it involves running the
program with the dummy symbols and supplying minimal definitions
for each that triggers the problem. With just one or two
translation units, reducing them to a small test case can then
be fully automated by running multidelta on them.
More information about the Gcc-help