profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/eugenis/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

llvm/llvm-project 10424

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

android/ndk 1160

The Android Native Development Kit

google/kmsan 279

KernelMemorySanitizer, a detector of uses of uninitialized memory in the Linux kernel

kcc/fuzzing-with-sanitizers 23

Tools, documentation and test inputs for fuzzing opensource projects with AddressSanitizer and friends.

eugenis/wesnoth-nacl-build 11

Various information and stuff for building Wesnoth for NativeClient

eugenis/jumpnbump-nacl 10

NativeClient port of Jump'n'Bump

eugenis/sdl-nacl 10

Native Client port of LibSDL (OUT-OF-DATE; visit nacl-ports at code.google.com)

eugenis/sdltest 8

A minimal SDL/NaCl example

eugenis/boost-nacl 7

NativeClient port of Boost

eugenis/digger-nacl 4

NativeClient port of Digger game

issue commentgoogle/sanitizers

HWSan on AARCH64 depends on the page size

Using pagesize here would be wasteful - ex. on Android we default to a single 4Kb page for the stack ring buffer. I'd rather replace the mmap in SavedStackAllocations with InternalAlloc , this should solve the problem.

There is also an efficiency issue in HwasanThreadList::DontNeedThread - if the buffer is smaller than a page, it will never be able to release anything. That's a bit harder to fix, and I'm not sure how significant it actually is.

On Sat, Sep 18, 2021 at 5:51 PM Andrew Pinski ***@***.***> wrote:

From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102144: The RingBufferSize inside hwasan/hwasan_thread_list.h depends on the page size being 4k. This does not work with 64k pages and most likely won't work with 16k pages too. This patch works for me with 64k page size but it really really be using the pagesize rather than a hard coded #:

diff --git a/libsanitizer/hwasan/hwasan_thread_list.h b/libsanitizer/hwasan/hwasan_thread_list.h index 15916a802d6..c13c5910b95 100644 --- a/libsanitizer/hwasan/hwasan_thread_list.h +++ b/libsanitizer/hwasan/hwasan_thread_list.h @@ -57,7 +57,7 @@ static uptr RingBufferSize() { // FIXME: increase the limit to 8 once this bug is fixed: // https://bugs.llvm.org/show_bug.cgi?id=39030 for (int shift = 1; shift < 7; ++shift) {

  • uptr size = 4096 * (1ULL << shift);

  • uptr size = (64*4096) * (1ULL << shift); if (size >= desired_bytes) return size; }

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1446, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SWO3IYLJ4Z5PDKNBQDUCUX2TANCNFSM5EJX6BCA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

apinski-cavium

comment created time in 4 days

push eventllvm/llvm-project

Evgenii Stepanov

commit sha f89ebe108e6f316a7ef293869e420491992b84cc

Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR in the sanitizer symbolizer build. In this mode libc++ headers end up in two directories: * include/<triple>/c++/v1 for the site config header * include/c++/v1 for everything else Also switch from -I to -isystem. Differential Revision: https://reviews.llvm.org/D108841

view details

push time in a month

push eventllvm/llvm-zorg

Evgenii Stepanov

commit sha 6f251765b9c4be1c7c76a2ea57c5ca9602f79003

Use -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF On sanitizer bots, revert to all runtime libraries in a common dir for now.

view details

push time in a month

push eventllvm/llvm-zorg

Evgenii Stepanov

commit sha 1f54ae1a4599a5d0a36bd99b73d449bc08e58042

Find libc++ in the per-target runtime directory Fixes build after "[CMake] Enable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR by default on Linux. Differential Revision: https://reviews.llvm.org/D108786

view details

push time in a month

push eventllvm/llvm-project

Evgenii Stepanov

commit sha 8a570a873b25af4c718a16caa214b4f7bc14e6d6

[hwasan] Support malloc in atfork. Before this change we were locking the StackDepot in the fork() interceptor. This results in a deadlock when allocator functions are used in a pthread_atfork() callback. Instead, set up a pthread_atfork() callback at init that locks/unlocks both StackDepot and the allocator. Since our callback is set up very early, the pre-fork callback is executed late, and both post-fork ones are executed early, which works perfect for us. Differential Revision: https://reviews.llvm.org/D108063

view details

push time in a month

push eventllvm/llvm-project

Evgenii Stepanov

commit sha c9ce76febb5e1cba5485a18305d3b4e305caedd8

(NFC) clang-format hwasan/hwasan_linux.cpp Differential Revision: https://reviews.llvm.org/D108224

view details

push time in a month

push eventllvm/llvm-project

Evgenii Stepanov

commit sha 8c23669eeb189a94aa6caacf8e1206175586aaad

[hwasan] Ignore lit config.enable_aliases on non-x86. This re-enables a number of Android tests that have been lost in check-hwasan. Differential Revision: https://reviews.llvm.org/D108064

view details

push time in a month

push eventgoogle/sanitizers

Evgenii Stepanov

commit sha db7415ce31d5d3146e3754ffcbc57c6d6f320162

A utility to dump MTE tags by PID.

view details

push time in 2 months

issue commentandroid/ndk

[FR] use `-Bsymbolic-non-weak-functions` by default if it lands?

Please at least make sure it does not apply to malloc() and friends - that would break LD_PRELOAD-style interposition of the allocator. ASan on non-arm64 is still a thing (HWASan would not care).

DanAlbert

comment created time in 2 months

issue commentgoogle/sanitizers

memory sanitizer: UUM not triggered when program compiled with O0

This is clever!

On Mon, Jul 19, 2021 at 3:39 PM Kris Kwiatkowski ***@***.***> wrote:

Some more context to that: https://www.amongbytes.com/post/20210709-testing-constant-time/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1424#issuecomment-882907203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SUSVVWQPYIP4XZ6FQLTYSSQ7ANCNFSM474KJQYQ .

kriskwiatkowski

comment created time in 2 months

issue commentgoogle/sanitizers

memory sanitizer: UUM not triggered when program compiled with O0

Right. MSan is far from precise in shadow tracking. In general, I'd like it to be more aggressive (ex. most of arithmetic propagation that is done with or(s1, s2) could be sign-extend(or(s1, s2) != 0) ) because even one undefined bit in arithmetic is UB, but that needs to be balanced against runtime performance. Also, MSan operates on LLVM IR, and IR semantics are different from C - ex. bit ops and even and </> comparisons are used to implement bitfields so they must be OK with partially-initialized data.

kriskwiatkowski

comment created time in 2 months

issue closedgoogle/sanitizers

Bug or Feature? I fail to suppress MSan error reporting in `memcmp()`

Ubuntu clang version 11.0.0-2~ubuntu20.04.1

I have a suppression file that successfully suppresses a number of errors for MemorySanitizer. But I fail to suppress an error reporting for the function memcmp both with this suppression line fun:memcmp, and this one fun:*memcmp*.

Is it a bug or feature?

Details. I run my binary with MSan. The MSan reports an issue in a call (I changed formatting a bit for readability):

1: ==1699==WARNING: MemorySanitizer: use-of-uninitialized-value
1:     #0 0x754bc8 in Catch::(anonymous namespace)::parseSpecialTag(std::__cxx11::basic_string<char, 
                                                                                               std::char_traits<char>, 
                                                                                               std::allocator<char> > const&) 
            <Removed>/src/Qir/Runtime/bin/Debug/../../../Common/externals/catch2/catch.hpp:14014:40

I successfully suppress this report with the following line in the suppression file: fun:*Catch*parseSpecialTag*

The execution continues and this same function makes a chain of calls eventually resulting in a call to memcmp() (I changed the output formatting for readability):

1: Uninitialized bytes in MemcmpInterceptorCommon at offset 0 inside [0x7fff8614fb50, 5)
1: ==3979==WARNING: MemorySanitizer: use-of-uninitialized-value
1:     #0 0x440f6e in memcmp 
            (<Removed>/src/Qir/Runtime/bin/Debug/unittests/qir-runtime-unittests+0x440f6e)
1:     #1 0x7f4c2d1f01ed in std::__cxx11::basic_string<char, 
                                                       std::char_traits<char>, 
                                                       std::allocator<char> 
                                                      >::compare(char const*) const 
            (/lib/x86_64-linux-gnu/libstdc++.so.6+0x1451ed)
1:     #2 0x5c57e6 in bool std::operator==<char, 
                                           std::char_traits<char>, 
                                           std::allocator<char> 
                                          >(std::__cxx11::basic_string<char, 
                                                                       std::char_traits<char>, 
                                                                       std::allocator<char> > const&, 
                                            char const*) 
            /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/basic_string.h:6177:20
1:     #3 0x754aab in Catch::(anonymous namespace)::parseSpecialTag(std::__cxx11::basic_string<char, 
                                                                                               std::char_traits<char>, 
                                                                                               std::allocator<char> > const&) 
            <Removed>/src/Qir/Runtime/bin/Debug/../../../Common/externals/catch2/catch.hpp:14015:21

I try to suppress this reporting by adding lines to the suppression file, suppression lines fun:memcmp, fun:*memcmp*. But none of these lines suppresses the reporting. Is it a bug or feature or do I miss something? What can I do to suppress and move forward?

See also related issue #1428

closed time in 2 months

kuzminrobin

issue commentgoogle/sanitizers

Bug or Feature? I fail to suppress MSan error reporting in `memcmp()`

That's because the check is in the interceptor ("Uninitialized bytes in MemcmpInterceptorCommon"), those are not affected by the suppression file. We don't have a good way of disabling interceptors - normally you don't want to disable them globally, but only for calls from a specific function or file or something like that.

And yes, IMHO non-instrumented libstdc++ is impractical.

On Mon, Jul 12, 2021 at 5:19 PM Robin Kuzmin ***@***.***> wrote:

If this cannot be resolved without instrumenting libstdc++, then feel free to close this issue.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1429#issuecomment-878682443, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SQ5OQ3VKTOAKGZMLYLTXOBATANCNFSM5ABRBM7A .

kuzminrobin

comment created time in 2 months

issue closedgoogle/sanitizers

HWAddressSanitizer: bad pointer 0x000000000030

Android logcat: 07-12 21:10:38.556 30584 30616 I app_process64: HWAddressSanitizer: bad pointer 0x000000000030 07-12 21:10:38.556 30584 30616 I app_process64: ==30584==HWAddressSanitizer CHECK failed: out/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_allocator_secondary.h:177 "((IsAligned(reinterpret_cast<uptr>(p), page_size_))) != (0)" (0x0, 0x0) 07-12 21:10:38.574 30584 30616 I app_process64: #0 0x7f2a1234e0 (/apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so+0x184e0) 07-12 21:10:38.574 30584 30616 I app_process64: #1 0x7f2a13567c (/apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so+0x2a67c) 07-12 21:10:38.574 30584 30616 I app_process64: #2 0x7f2a125194 (/apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so+0x1a194) 07-12 21:10:38.574 30584 30616 I app_process64: #3 0x7f2a125700 (/apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so+0x1a700) 07-12 21:10:38.574 30584 30616 I app_process64: #4 0x7f2a12870c (/apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so+0x1d70c)

backtrace: #00 pc 000000000005bee4 /apex/com.android.runtime/lib64/bionic/libc.so (abort+356) (BuildId: 9f62d65af200562af6856c16fb045819) #01 pc 000000000002b710 /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__sanitizer::Abort()+60) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #02 pc 000000000002a5f8 /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__sanitizer::Die()+204) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #03 pc 000000000001853c /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__hwasan::HWAsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long)+176) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #04 pc 000000000002a67c /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long)+112) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #05 pc 000000000001a194 /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__hwasan::AP64>, __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::GetMetaData(void const*)+300) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #06 pc 000000000001a700 /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__hwasan::HwasanDeallocate(__sanitizer::StackTrace*, void*)+168) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #07 pc 000000000001d70c /apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so (__sanitizer_free+176) (BuildId: c43f06ecec3119e9e2e588c25348b5a62e819c42) #08 pc 0000000000766de8 /data/app/~~Y0kQSuI_iS-Ms9klmfJm6g==/com.lark.jsengineapp-sxGpJ0TgC7Ywy4sFOHgsbQ==/lib/arm64/libv8_libfull.cr.so #09 pc 0000000000765d80 /data/app/~~Y0kQSuI_iS-Ms9klmfJm6g==/com.lark.jsengineapp-sxGpJ0TgC7Ywy4sFOHgsbQ==/lib/arm64/libv8_libfull.cr.so (v8::internal::Isolate::Init(v8::internal::ReadOnlyDeserializer*, v8::internal::StartupDeserializer*)+1140) #10 pc 000000000076663c /data/app/~~Y0kQSuI_iS-Ms9klmfJm6g==/com.lark.jsengineapp-sxGpJ0TgC7Ywy4sFOHgsbQ==/lib/arm64/libv8_libfull.cr.so #11 pc 000000000090cb48 /data/app/~~Y0kQSuI_iS-Ms9klmfJm6g==/com.lark.jsengineapp-sxGpJ0TgC7Ywy4sFOHgsbQ==/lib/arm64/libv8_libfull.cr.so #12 pc 0000000000509074 /data/app/~~Y0kQSuI_iS-Ms9klmfJm6g==/com.lark.jsengineapp-sxGpJ0TgC7Ywy4sFOHgsbQ==/lib/arm64/libv8_libfull.cr.so (v8::Isolate::Initialize(v8::Isolate*, v8::Isolate::CreateParams const&)+264) #13 pc 0000000000509184 /data/app/~~Y0kQSuI_iS-Ms9klmfJm6g==/com.lark.jsengineapp-sxGpJ0TgC7Ywy4sFOHgsbQ==/lib/arm64/libv8_libfull.cr.so (v8::Isolate::New(v8::Isolate::CreateParams const&)+36)

closed time in 2 months

LitterSun

issue commentgoogle/sanitizers

HWAddressSanitizer: bad pointer 0x000000000030

Your code calls free(0x30). It is a bad pointer.

LitterSun

comment created time in 2 months

issue commentgoogle/sanitizers

Sanitizers: Feature Request: Apply `__attribute__((no_sanitize("<check>")))` to the _included header_.

Just to be clear, you are using something like -fsanitize=integer? Because implicit sign change is not undefined behavior, and it is not part of -fsanitize=undefined.

That also means that it is NOT a bug in the gcc header and you'll have to deal with it on your side.

The attributes do not apply to the scope like that, but you could use an ignore list. The names have to be mangled, but they are regular expressions, so just match something like uniform_int_distribution.*operator. Or by source path ("src:" entry in the ignore list), those check both the main source file as well the source location on the check (so should match the header name).

On Fri, Jul 2, 2021 at 2:35 PM Robin Kuzmin ***@***.***> wrote:

I have an impression that for my problem the most reliable solution would be the ability to apply attribute((no_sanitize("<check>"))) to the whole included header. Something like this:

attribute((no_sanitize("implicit-integer-sign-change"))) { #include <random> }

If you know better solutions, please share.

Explanation: I have a function that invokes the standard random number generator https://en.cppreference.com/w/cpp/numeric/random/uniform_int_distribution#Example. Something like this:

#include <random>int64_t drawrandomint(int64_t minimum, int64_t maximum) { if(minimum > maximum) { // Fail }

// https://en.cppreference.com/w/cpp/numeric/random/uniform_int_distribution
// https://en.cppreference.com/w/cpp/numeric/random
thread_local static std::mt19937_64 gen(randomizeSeed
                                            ? std::random_device()() :  // Default
                                            0);                         // For test purposes only.

lastGeneratedRndI64 = std::uniform_int_distribution<int64_t>(minimum, maximum)(gen);
return lastGeneratedRndI64;

}

I enabled UBSan (-fsanitize=undefined) and one of the issues reported is like this:

3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:17: runtime error: implicit conversion from type 'std::uniform_int_distribution<long>::result_type' (aka 'long') of value -9223372036854775808 (64-bit, signed) to type 'unsigned long' changed the value to 9223372036854775808 (64-bit, unsigned) 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:17 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9: runtime error: implicit conversion from type 'unsigned long' of value 10154649009328186736 (64-bit, unsigned) to type 'std::uniform_int_distribution<long>::result_type' (aka 'long') changed the value to -8292095064381364880 (64-bit, signed) 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9 in

The issue is reported by a check implicit-integer-sign-change in the standard library code. I don't want to disable the check globally. I want to disable it for the smallest sufficient fragment.

Here https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#disabling-instrumentation-with-attribute-no-sanitize-undefined, here https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#suppressing-errors-in-recompiled-code-ignorelist, and here https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#runtime-suppressions the documentation explains how to disable the sanitizer check for a particular function, source file, or library.

I try to apply the attribute attribute((no_sanitize("implicit-integer-sign-change"))) to my function drawrandomint(). But it doesn't help me because the attribute covers my function only, but not the nested calls - the standard functions that my function calls. I try to suppress the issue reporting for a particular function in the standard library. I break in the debugger at the moment where the issue is reported and see that the guilty function is named

long std::uniform_int_distribution<long>::operator(this=0x00007ffff78990d8, __urng=0x00007ffff78ac758, __param=0x00007ffff78990d8)
<std::mersenne_twister_engine<unsigned long, 64ul, 312ul, 156ul, 31ul, 13043109905998158313ul, 29ul,
6148914691236517205ul, 17ul, 8202884508482404352ul, 37ul, 18444473444759240704ul, 43ul, 6364136223846793005ul> >
(std::mersenne_twister_engine<unsigned long, 64ul, 312ul, 156ul, 31ul, 13043109905998158313ul, 29ul, 6148914691236517205ul,
17ul, 8202884508482404352ul, 37ul, 18444473444759240704ul, 43ul, 6364136223846793005ul>&,
std::uniform_int_distribution<long>::param_type const&)

The tricky part here is the fragment "std::mersenne_twister_engine<unsigned long". It originates from the standard definition https://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine "std::mersenne_twister_engine<std::uint_fast64_t". The type alias std::uint_fast64_t is defined differently in different implementations. My team is targeting at portable solution, the code is compiled on different platforms. Overall the function name is also rather tricky, and I don't remember the documentation to mention anything related to mangling when suppressing based on the function names. The bottom line here is that it is hard for me to suppress the check for a particular function.

I try to suppress the check for a particular file in the standard library. I see that the guilty function is in the file /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h. The file name is not standard (not mentioned in the C++17 standard). File path is likely different on different architectures where our CI build servers build our code. The bottom line here is that it is hard for me to suppress the check for a particular file.

The guilty fragment is statically linked to our dynamic library. Disabling the check for the whole our dynamic library is not something that we want.

Grand total here is that it is hard for me to suppress the check based on the function name, file path, and library. This check is the simple one of the two reported.

What could probably help me is the ability to apply the check-disabling attribute to a certain scope ({ .. }), in particular to the whole included header:

#if defined(clang)attribute((no_sanitize("implicit-integer-sign-change"))) { #endif

#include <random>

#if defined(clang) } #endif

(I realize that such a header will need to be included first. Otherwise the other headers may already include that header, and it will be too late to disable the check for the second inclusion of that header)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1423, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SV532EICTYWMLYVCWDTVYWKTANCNFSM47XNAMZA .

kuzminrobin

comment created time in 3 months

issue closedgoogle/sanitizers

Doc: UBSan: `unsigned-integer-overflow` _is_ part of `-fsanitize=undefined`.

Here I see the fragment:

-fsanitize=undefined: All of the checks listed above other than float-divide-by-zero, unsigned-integer-overflow,

The fragment makes an impression that if I use -fsanitize=undefined but don't use -fsanitize=unsigned-integer-overflow, then the unsigned integer overflows will not be reported. But they are reported, as part of bare -fsanitize=undefined and as part of bare -fsanitize=integer. Because -fsanitize=unsigned-integer-overflow is a part of -fsanitize=integer, which is a part of -fsanitize=undefined.

That is why I suggest a change in the documentation:

-fsanitize=undefined: All of the checks listed above other than float-divide-by-zero, unsigned-integer-overflow,

closed time in 3 months

kuzminrobin

issue commentgoogle/sanitizers

UBSan: Feature Request: Enable the check group, except one particular check.

That would be good!

On Fri, Jul 2, 2021 at 10:33 AM Diane Meirowitz ***@***.***> wrote:

I am in the process of doing another update to that file so I can clarify the -fno-.. syntax if you would like.

Diane

On Jul 2, 2021, at 1:21 PM, Evgenii Stepanov ***@***.***> wrote:

On Thu, Jul 1, 2021 at 5:03 PM Robin Kuzmin ***@***.***> wrote:

I'll check later, in the meantime FYI: I fail to find any description mentioning -fno-sanitize=...

It's tricky to find - search for "-f[no-]sanitize". And indeed there is no indication of how exactly this flag works - all -fsanitize and -fno-sanitize flags are evaluated left to right and update the set of enabled sanitizers so you can add a group and then subtract some. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1422#issuecomment-873154292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SR52YEMUNH3CSCUAWTTVXZ53ANCNFSM47VP6F3A .

kuzminrobin

comment created time in 3 months

issue commentgoogle/sanitizers

UBSan: Feature Request: Enable the check group, except one particular check.

On Thu, Jul 1, 2021 at 5:03 PM Robin Kuzmin ***@***.***> wrote:

I'll check later, in the meantime FYI: I fail to find any description mentioning -fno-sanitize=...

It's tricky to find - search for "-f[no-]sanitize". And indeed there is no indication of how exactly this flag works - all -fsanitize and -fno-sanitize flags are evaluated left to right and update the set of enabled sanitizers so you can add a group and then subtract some.

kuzminrobin

comment created time in 3 months

issue commentgoogle/sanitizers

Doc: UBSan: `unsigned-integer-overflow` _is_ part of `-fsanitize=undefined`.

On Thu, Jul 1, 2021 at 3:00 PM Robin Kuzmin ***@***.***> wrote:

clang++-11 --version

Ubuntu clang version 11.0.0-2~ubuntu20.04.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin

I compile and link your example with all my flags identical to the build process, and see the silence for -fsanitize=undefined:

$ /home/rokuzmin/ed/install/cmake-3.20.4-linux-x86_64/bin/cmake -E __run_co_compile --tidy="clang-tidy-11;--extra-arg-before=--driver-mode=g++" --source=./a.cpp -- /usr/bin/clang++-11 -I../../../Common/externals/catch2 -I../../../Common/Include -I../../../Runtime/public -Werror -Weverything -Wno-c++98-compat-pedantic -Wno-old-style-cast -Wno-covered-switch-default -Wno-c99-extensions -Wno-padded -Wno-weak-vtables -Wno-global-constructors -Wno-exit-time-destructors -Wno-extra-semi-stmt -fsanitize=undefined -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -DDEBUG -std=gnu++17 -MD -MT ./a.cpp.o -MF ./a.cpp.o.d -o ./a.cpp.o -c ./a.cpp

$ /usr/bin/clang++-11 -Werror -Weverything -Wno-c++98-compat-pedantic -Wno-old-style-cast -Wno-covered-sw itch-default -Wno-c99-extensions -Wno-padded -Wno-weak-vtables -Wno-global-constructors -Wno-exit-time-destructors -Wno-extra-semi-stmt -fsanitize=undefined -fno-omit-frame-pointer -fno-optimize-sib ling-calls -g -DDEBUG ./a.cpp.o

$ ./a.out

The following fragment https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks

-fsanitize=shift: Shift operators where the amount shifted is greater or equal to the promoted bit-width of the left hand side or less than zero, or where the left hand side is negative. For a signed left shift, also checks for signed overflow in C, and for unsigned overflow in C++.

makes me suspect that unsigned-integer-overflow could be a part of -fsanitize=shift which is likely a part of -fsanitize=undefined.

It's not. You can find all sanitizer group definitions here: https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Sanitizers.def

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1421#issuecomment-872576005, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SQNK63AMKJDSA6CPX3TVTQQLANCNFSM47VMSEXA .

kuzminrobin

comment created time in 3 months

issue commentgoogle/sanitizers

UBSan: Feature Request: Enable the check group, except one particular check.

Does -fsanitize=undefined -fno-sanitize=enum help?

On Thu, Jul 1, 2021 at 2:28 PM Robin Kuzmin ***@***.***> wrote:

In the UndefinedBehaviorSanitizer https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html doc page I don't see how to enable all the checks except one particular check, e.g. enable all -fsanitize=undefined except one -fsanitize=enum (this is just an example, not what I actually need at the moment).

Would be nice to have a mechanism like that.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1422, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SSUDQ7Y6CI64T2IOUDTVTMY5ANCNFSM47VP6F3A .

kuzminrobin

comment created time in 3 months

issue commentgoogle/sanitizers

Doc: UBSan: `unsigned-integer-overflow` _is_ part of `-fsanitize=undefined`.

Maybe you have other flags somewhere? What is the compiler version? Try this experiment:

int main() { volatile unsigned x = 2; for (int i = 0; i < 100; ++i) x *= x; }

-fsanitize=integer: runtime error: unsigned integer overflow: 65536 * 65536 cannot be represented in type 'unsigned int'

-fsanitize=undefined: silence

On Thu, Jul 1, 2021 at 1:43 PM Robin Kuzmin ***@***.***> wrote:

Here is the fragment of the log I got with bare -fsanitize=unsigned-integer-overflow:

3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:336:8: runtime error: unsigned integer overflow: 220632869 * 6364136223846793005 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:336:8 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.h:552:58: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.h:552:58 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:239:28: runtime error: unsigned integer overflow: 9223372036854775807 - 9223372036854775808 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:239:28 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:33: runtime error: unsigned integer overflow: 156 - 312 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:33 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:26: runtime error: unsigned integer overflow: 156 + 18446744073709551460 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:26 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:17: runtime error: implicit conversion from type 'std::uniform_int_distribution<long>::result_type' (aka 'long') of value -9223372036854775808 (64-bit, signed) to type 'unsigned long' changed the value to 9223372036854775808 (64-bit, unsigned) 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:17 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9: runtime error: implicit conversion from type 'unsigned long' of value 14735541592946606942 (64-bit, unsigned) to type 'std::uniform_int_distribution<long>::result_type' (aka 'long') changed the value to -3711202480762944674 (64-bit, signed) 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:15: runtime error: unsigned integer overflow: 17894863629008273705 + 9223372036854775808 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:15 in

And here is the fragment of the log I got with bare -fsanitize=undefined:

3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:336:8: runtime error: unsigned integer overflow: 1812533378 * 6364136223846793005 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:336:8 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.h:552:58: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.h:552:58 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:239:28: runtime error: unsigned integer overflow: 9223372036854775807 - 9223372036854775808 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:239:28 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:33: runtime error: unsigned integer overflow: 156 - 312 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:33 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:26: runtime error: unsigned integer overflow: 156 + 18446744073709551460 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:415:26 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:17: runtime error: implicit conversion from type 'std::uniform_int_distribution<long>::result_type' (aka 'long') of value -9223372036854775808 (64-bit, signed) to type 'unsigned long' changed the value to 9223372036854775808 (64-bit, unsigned) 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:17 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9: runtime error: implicit conversion from type 'unsigned long' of value 11434608098840624830 (64-bit, unsigned) to type 'std::uniform_int_distribution<long>::result_type' (aka 'long') changed the value to -7012135974868926786 (64-bit, signed) 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9 in 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:15: runtime error: unsigned integer overflow: 10621442073636048524 + 9223372036854775808 cannot be represented in type 'unsigned long' 3: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:15 in

Here is the diff that I see:

53c53< 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:336:8: runtime error: unsigned integer overflow: 220632869 * 6364136223846793005 cannot be represented in type 'unsigned long'---> 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/random.tcc:336:8: runtime error: unsigned integer overflow: 1812533378 * 6364136223846793005 cannot be represented in type 'unsigned long'65c65< 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9: runtime error: implicit conversion from type 'unsigned long' of value 14735541592946606942 (64-bit, unsigned) to type 'std::uniform_int_distribution<long>::result_type' (aka 'long') changed the value to -3711202480762944674 (64-bit, signed)---> 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:9: runtime error: implicit conversion from type 'unsigned long' of value 11434608098840624830 (64-bit, unsigned) to type 'std::uniform_int_distribution<long>::result_type' (aka 'long') changed the value to -7012135974868926786 (64-bit, signed)67c67< 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:15: runtime error: unsigned integer overflow: 17894863629008273705 + 9223372036854775808 cannot be represented in type 'unsigned long'---> 3: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/uniform_int_dist.h:284:15: runtime error: unsigned integer overflow: 10621442073636048524 + 9223372036854775808 cannot be represented in type 'unsigned long'

This makes me think that -fsanitize=unsigned-integer-overflow check is a part of the -fsanitize=undefined check group, directly or indirectly. I could be wrong saying that

-fsanitize=unsigned-integer-overflow is a part of -fsanitize=integer, which is a part of -fsanitize=undefined

But looks like -fsanitize=unsigned-integer-overflow is a part of some other check that is a part of -fsanitize=undefined.

That is why I suggest either a change in the documentation:

-fsanitize=undefined: All of the checks listed above other than float-divide-by-zero, unsigned-integer-overflow,

or a change in the behavior such that unsigned-integer-overflow is not reported during -fsanitize=undefined.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1421#issuecomment-872537842, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SXQIRFJTIURYWHJGDTTVTHPTANCNFSM47VMSEXA .

kuzminrobin

comment created time in 3 months

issue commentgoogle/sanitizers

Doc: UBSan: `unsigned-integer-overflow` _is_ part of `-fsanitize=undefined`.

Are you sure about this? Unsigned integer overflow is not part of -fsanitize=undefined, because it is not undefined.

-fsanitize=integer is also not part of -fsanitize=undefined, but they do overlap.

On Thu, Jul 1, 2021 at 1:13 PM Robin Kuzmin ***@***.***> wrote:

Here https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html I see the fragment:

-fsanitize=undefined: All of the checks listed above other than float-divide-by-zero, unsigned-integer-overflow,

The fragment makes an impression that if I use -fsanitize=undefined but don't use -fsanitize=unsigned-integer-overflow, then the unsigned integer overflows will not be reported. But they are reported, as part of bare -fsanitize=undefined and as part of bare -fsanitize=integer. Because -fsanitize=unsigned-integer-overflow is a part of -fsanitize=integer, which is a part of -fsanitize=undefined.

That is why I suggest a change in the documentation:

-fsanitize=undefined: All of the checks listed above other than float-divide-by-zero, unsigned-integer-overflow,

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/sanitizers/issues/1421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADG4SSJXTSBMKURVA343TLTVTD7HANCNFSM47VMSEXA .

kuzminrobin

comment created time in 3 months