[cfe-dev] Why does integer overflow sanitizer exits the program with zero exit code

Kostya Serebryany via cfe-dev cfe-dev at lists.llvm.org
Fri Oct 23 11:30:38 PDT 2015


On Fri, Oct 23, 2015 at 11:27 AM, Riyad Parvez <riyad.parvez at uwaterloo.ca>
wrote:

> Thanks! It works on the latest version of clang, but I was using clang 3.4
> where it didn't work.
>

3.4 was loooong ago.


>
> On a more related note, SIGABRT better indicator of bugs than non-zero
> exit status. So I've tried "ASAN_OPTIONS=abort_on_error=1" option which
> works for address sanitizer where program exists with SIGABRT. But
> "UBSAN_OPTIONS=abort_on_error=1" doesn't exit with SIGABRT. Is there any
> way to make overflow sanitizer exit with SIGABRT similar to address
> sanitizer?
>

Just checked:

% clang -fsanitize=address,signed-integer-overflow int-overflow.c &&
UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 ./a.out ; echo EXIT STATUS:
$?
int-overflow.c:5:5: runtime error: signed integer overflow: 1073741824 +
1073741824 cannot be represented in type 'int'
SUMMARY: AddressSanitizer: undefined-behavior int-overflow.c:5:5 in
Aborted (core dumped)
EXIT STATUS: 134



>
> On Fri, Oct 23, 2015 at 1:06 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Fri, Oct 23, 2015 at 7:08 AM, Riyad Parvez <riyad.parvez at uwaterloo.ca>
>> wrote:
>>
>>> Thanks for the reply.
>>>
>>> I am developing a fuzzer and interested to find overflows.
>>>
>>
>> So am I :)
>> llvm.org/docs/LibFuzzer.html
>>
>>
>>> Is there any way to detect when errors are detected? To explain more, I
>>> have instrumented the binary to see which functions are called in run-time.
>>> What are the functions that are called when overflow is detected? When
>>> these functions are called I will know overflow is detected.
>>>
>>>
>>> On Thu, Oct 22, 2015 at 8:08 PM, Kostya Serebryany <kcc at google.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 22, 2015 at 11:52 AM, Riyad Parvez via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> With "-fsanitize=integer" flag, when an overflow is detected the
>>>>> program is terminated with zero exit code.
>>>>>
>>>>
>>>> You can change this behavior by using env. var.
>>>> UBSAN_OPTIONS=halt_on_error=1
>>>>
>>>>
>>> I've tried this; didn't work.
>>>
>>
>> What exactly do you run?
>>
>> Here is what works for me:
>>
>> % cat int-overflow.c
>> #include <stdio.h>
>> int x;
>> int main(int argc, char **argv) {
>>   x += 1 << 30;
>>   x += 1 << 30;
>>   printf("%d\n", x);
>>   return 0;
>> }
>>
>>
>> % clang -fsanitize=signed-integer-overflow int-overflow.c && ./a.out ;
>> echo EXIT STATUS: $?
>> int-overflow.c:5:5: runtime error: signed integer overflow: 1073741824 +
>> 1073741824 cannot be represented in type 'int'
>> -2147483648
>> EXIT STATUS: 0
>> % clang -fsanitize=signed-integer-overflow int-overflow.c &&
>> UBSAN_OPTIONS=halt_on_error=1 ./a.out ; echo EXIT STATUS: $?
>> int-overflow.c:5:5: runtime error: signed integer overflow: 1073741824 +
>> 1073741824 cannot be represented in type 'int'
>> EXIT STATUS: 1
>> %
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>> (Not sure if this is properly documented anywhere. Alexey? )
>>>>
>>>>
>>>>> But with "-fsanitize=address" flag, the program terminates with
>>>>> non-zero exit code. I think the address sanitizer behavior of non-zero exit
>>>>> code is more intuitive since the program did exit in error. Is there any
>>>>> reason integer overflow sanitizer exits the program with zero exit code?
>>>>>
>>>>
>>>> One of the reasons, maybe:
>>>> Programs are more often ubsan-unclean than asan-unclean, and halting on
>>>> every ubsan message makes it harder to deploy the tool.
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Riyad
>>>>>
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151023/c50c66b8/attachment.html>


More information about the cfe-dev mailing list