This repository was archived by the owner on Mar 28, 2020. It is now read-only.
Fixed a compiler warning about undefined #define #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fredriss
pushed a commit
that referenced
this pull request
Jun 4, 2016
This should fail on frame #1 and show what that should actually be. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@271783 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jul 16, 2016
c:\lipo\work\asan\b_llvm>c:\lipo\work\asan\b_llvm\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\null_deref.cc.tmp
=================================================================
==5488==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000028 (pc 0x7ff701f91067 bp 0x000c8cf8fbf0 sp 0x000c8cf8fbb0 T0)
==5488==The signal is caused by a READ memory access.
==5488==Hint: address points to the zero page.
#0 0x7ff701f91066 in NullDeref(int *) C:\lipo\work\asan\llvm\projects\compiler-rt\test\asan\TestCases\null_deref.cc:15:10
#1 0x8a0388830a67 (<unknown module>)
The reason was symbols was not initilized. In fact, it was first inited
with a call to stack.Print(), which calls
WinSymbolizerTool::SymbolizePC, then InitializeDbgHelpIfNeeded().
Since the StackWalk was performed before the stack.Print(), stack frames
where not gathered correctly.
There should be a better place to initialize symbols. For now, this
patch makes the test happy.
Patch by Wei Wang
Differential Revision: https://reviews.llvm.org/D22410
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@275580 91177308-0d34-0410-b5e6-96231b3b80d8
gottesmm
pushed a commit
that referenced
this pull request
Sep 11, 2016
The stack trace produced by TSan on MIPS is:
Previous write of size 8 at 0x0120ed2930 by thread T1:
#0 memset
/home/slt/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:678
(race_on_mutex.c.tmp+0x0120071808)
#1 __GI___pthread_mutex_init
/build/glibc-g99ldr/glibc-2.19/nptl/pthread_mutex_init.c:84
(libpthread.so.0+0x000000d634)
#2 <null>
/home/slt/LLVM/llvm/projects/compiler-rt/test/tsan/race_on_mutex.c:11 (race_on_mutex.c.tmp+0x01200ea59c)
Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17796
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@263778 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Sep 20, 2016
Enable more ignores when we start crashing.
Unwind in CHECK SIGSEGVs if happens early:
FATAL: ThreadSanitizer CHECK failed: ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105 "((beg)) <= ((end))" (0x8000000000, 0x4000000000)
Program received signal SIGSEGV, Segmentation fault.
__tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true,
create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208
208 u32 idx0 = *meta;
(gdb) bt
#0 __tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true,
create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208
#1 0x00000000004a965f in __tsan::MetaMap::GetOrCreateAndLock (this=<optimized out>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true)
at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:198
#2 0x00000000004a162a in __tsan::Release (thr=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:395
#3 0x000000000046cc40 in __interceptor_pthread_once (o=0x7ffff71a5890 <once_regsizes>, f=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1334
#4 0x00007ffff6f9fe86 in __gthread_once (__func=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>, __once=0x7ffff71a5890 <once_regsizes>) at ./gthr-default.h:699
#5 uw_init_context_1 (context=context@entry=0x7fffffffd6d0, outer_cfa=outer_cfa@entry=0x7fffffffd980, outer_ra=0x437d13 <__sanitizer::BufferedStackTrace::SlowUnwindStack(unsigned long, unsigned int)+67>)
at ../../../src/libgcc/unwind-dw2.c:1572
#6 0x00007ffff6fa06a8 in _Unwind_Backtrace (trace=0x437c30 <__sanitizer::Unwind_Trace(_Unwind_Context*, void*)>, trace_argument=0x7fffffffd980) at ../../../src/libgcc/unwind.inc:283
#7 0x0000000000437d13 in __sanitizer::BufferedStackTrace::SlowUnwindStack (this=0x7ffff6103208, pc=pc@entry=4863574, max_depth=max_depth@entry=256)
at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:125
#8 0x0000000000434f4a in __sanitizer::BufferedStackTrace::Unwind (this=this@entry=0x7ffff6103208, max_depth=max_depth@entry=256, pc=pc@entry=4863574, bp=bp@entry=0, context=context@entry=0x0,
stack_top=stack_top@entry=0, stack_bottom=stack_bottom@entry=0, request_fast_unwind=request_fast_unwind@entry=false) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc:76
#9 0x00000000004a36b3 in PrintCurrentStackSlow (pc=4863574) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:696
#10 __tsan::TsanCheckFailed (file=<optimized out>, line=<optimized out>, cond=<optimized out>, v1=<optimized out>, v2=<optimized out>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:44
#11 0x000000000042dfd6 in __sanitizer::CheckFailed (file=file@entry=0x4b9fd0 "../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc", line=line@entry=105,
cond=cond@entry=0x4ba049 "((beg)) <= ((end))", v1=v1@entry=549755813888, v2=v2@entry=274877906944) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79
#12 0x00000000004aa36c in ProtectRange (end=274877906944, beg=549755813888) at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105
#13 __tsan::CheckAndProtect () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:133
#14 0x00000000004a9e95 in __tsan::InitializePlatform () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_linux.cc:280
#15 0x0000000000497e73 in __tsan::Initialize (thr=0x7ffff7f91800) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl.cc:343
#16 0x00007ffff7dea25a in _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffdb88, env=0x7fffffffdb98) at dl-init.c:111
#17 0x00007ffff7ddb30a in _dl_start_user () at rtld.c:871
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@281969 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Feb 11, 2017
Summary:
GET_CALLER_PC doesn't work properly on 31-bit s390, as pointers are 31-bit, the MSB bit can be set when the return address is copied into integer.
This causes e.g. errors like:
#0 0xfdadb129 (<unknown module>)
#1 0x7da5e1d1 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) ../../../../../libsanitizer/asan/asan_stack.h:50
#2 0x7da5e1d1 in __asan::ErrorGeneric::Print() ../../../../../libsanitizer/asan/asan_errors.cc:482
#3 0x7db178d5 in __asan::ErrorDescription::Print() ../../../../../libsanitizer/asan/asan_errors.h:360
#4 0x7db178d5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() ../../../../../libsanitizer/asan/asan_report.cc:167
#5 0x7db178d5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../../libsanitizer/asan/asan_report.cc:397
#6 0x7dadb14f in __interceptor_memcmp ../../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
#7 0x400cf5 in main /home/jakub/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:14
#8 0x7d807215 in __libc_start_main (/lib/libc.so.6+0x1a215)
#9 0x4007ed (/home/jakub/gcc/obj/gcc/testsuite/memcmp-1.exe+0x4007ed)
The actual return PC inside __interceptor_memcmp was 0x7dadb129 rather than 0xfdadb129.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29824
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@294793 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jun 4, 2017
atos is apparently not able to resolve symbol addresses properly on i386-darwin reliably any more. This is causing bot flakiness: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/6841 There have not been any SDK changes on the bot as of late. /Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/llvm/projects/compiler-rt/test/asan/TestCases/Darwin/atos-symbolizer.cc:20:12: error: expected string not found in input // CHECK: #1 0x{{.*}} in main {{.*}}atos-symbolizer.cc:[[@LINE-4]] ^ <stdin>:35:27: note: scanning from here #0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56) ^ <stdin>:35:27: note: with expression "@LINE-4" equal to "16" #0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56) ^ <stdin>:36:168: note: possible intended match here #1 0xb6f20 in main (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/tools/clang/runtime/compiler-rt-bins/test/asan/I386DarwinConfig/TestCases/Darwin/Output/atos-symbolizer.cc.tmp:i386+0x1f20) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304674 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Dec 21, 2017
Summary: __builtin_clz used for Log calculation returns an undefined result when argument is 0. I noticed that issue when was testing some fuzzers: ``` /src/libfuzzer/FuzzerTracePC.h:282:33: runtime error: shift exponent 450349 is too large for 32-bit type 'uint32_t' (aka 'unsigned int') #0 0x43d83f in operator() /src/libfuzzer/FuzzerTracePC.h:283:33 #1 0x43d83f in void fuzzer::TracePC::CollectFeatures<fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*)::$_1>(fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*)::$_1) const /src/libfuzzer/FuzzerTracePC.h:290 #2 0x43cbd4 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:445:7 #3 0x43e5f1 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:706:5 #4 0x43e9e1 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:739:3 #5 0x432f8c in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:754:6 #6 0x42ee18 in main /src/libfuzzer/FuzzerMain.cpp:20:10 #7 0x7f17ffeb182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #8 0x407838 in _start (/out/rotate_fuzzer+0x407838) Reviewers: kcc Reviewed By: kcc Subscribers: llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D41457 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@321211 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jun 11, 2018
Summary:
Running sanitized 32-bit x86 programs on glibc 2.27 crashes at startup, with:
ERROR: AddressSanitizer: SEGV on unknown address 0xf7a8a250 (pc 0xf7f807f4 bp 0xff969fc8 sp 0xff969f7c T16777215)
The signal is caused by a WRITE memory access.
#0 0xf7f807f3 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x127f3)
#1 0xf7a92599 (/lib/libasan.so.5+0x112599)
#2 0xf7a80737 (/lib/libasan.so.5+0x100737)
#3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f)
#4 0xf7f6eb49 (/lib/ld-linux.so.2+0xb49)
The problem is that glibc changed the calling convention for the GLIBC_PRIVATE
symbol that sanitizer uses (even when it should not, GLIBC_PRIVATE is exactly
for symbols that can change at any time, be removed etc.), see
https://sourceware.org/ml/libc-alpha/2017-08/msg00497.html
Fixes google/sanitizers#954
Patch By: Jakub Jelinek
Reviewed By: vitalybuka, Lekensteyn
Differential Revison: https://reviews.llvm.org/D44623
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@334363 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Feb 27, 2019
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/compiler-rt/test/asan/TestCases/Posix/bcmp_test.cc:14:12: error: CHECK: expected string not found in input
// CHECK: {{#1.*bcmp}}
^
<stdin>:2:57: note: scanning from here
==34677==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee93777c4 at pc 0x0001068a7285 bp 0x7ffee9377770 sp 0x7ffee9376ef8
^
<stdin>:6:20: note: possible intended match here
#2 0x106888e77 in main bcmp_test.cc:12
^
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354888 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Feb 28, 2019
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355013 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Aug 9, 2019
Summary: This bug occurred when a plug-in requested that a binary not be symbolized while the script is trying to symbolize a stack frame. In this case `self.frame_no` would not be incremented. This would cause subsequent stack frames that are symbolized to be incorrectly numbered. To fix this `get_symbolized_lines()` has been modified to take an argument that indicates whether the stack frame counter should incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)` is now used in in the case where we don't want to symbolize a line so that we can keep the frame counter increment in a single function. A test case is included. The test uses a dummy plugin that always asks `asan_symbolize.py` script to not symbolize the first binary that the script asks about. Prior to the patch this would cause the output to script to look something like ``` #0 0x0 #0 0x0 in do_access #1 0x0 in main ``` rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65495 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368373 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Aug 13, 2019
Summary: This bug occurred when a plug-in requested that a binary not be symbolized while the script is trying to symbolize a stack frame. In this case `self.frame_no` would not be incremented. This would cause subsequent stack frames that are symbolized to be incorrectly numbered. To fix this `get_symbolized_lines()` has been modified to take an argument that indicates whether the stack frame counter should incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)` is now used in in the case where we don't want to symbolize a line so that we can keep the frame counter increment in a single function. A test case is included. The test uses a dummy plugin that always asks `asan_symbolize.py` script to not symbolize the first binary that the script asks about. Prior to the patch this would cause the output to script to look something like ``` #0 0x0 #0 0x0 in do_access #1 0x0 in main ``` This is the second attempt at landing this patch. The first (r368373) failed due to failing some android bots and so was reverted in r368472. The new test is now disabled for Android. It turns out that the patch also fails for iOS too so it is also disabled for that family of platforms too. rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65495 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368603 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Aug 13, 2019
Summary: feature coverage is a useful signal that is available during the merge process, but was not printed previously. Output example: ``` $ ./fuzzer -use_value_profile=1 -merge=1 new_corpus/ seed_corpus/ INFO: Seed: 1676551929 INFO: Loaded 1 modules (2380 inline 8-bit counters): 2380 [0x90d180, 0x90dacc), INFO: Loaded 1 PC tables (2380 PCs): 2380 [0x684018,0x68d4d8), MERGE-OUTER: 180 files, 78 in the initial corpus MERGE-OUTER: attempt 1 INFO: Seed: 1676574577 INFO: Loaded 1 modules (2380 inline 8-bit counters): 2380 [0x90d180, 0x90dacc), INFO: Loaded 1 PC tables (2380 PCs): 2380 [0x684018,0x68d4d8), INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 1048576 bytes MERGE-INNER: using the control file '/tmp/libFuzzerTemp.111754.txt' MERGE-INNER: 180 total files; 0 processed earlier; will process 180 files now #1 pulse cov: 134 ft: 330 exec/s: 0 rss: 37Mb #2 pulse cov: 142 ft: 462 exec/s: 0 rss: 38Mb #4 pulse cov: 152 ft: 651 exec/s: 0 rss: 38Mb #8 pulse cov: 152 ft: 943 exec/s: 0 rss: 38Mb #16 pulse cov: 520 ft: 2783 exec/s: 0 rss: 39Mb #32 pulse cov: 552 ft: 3280 exec/s: 0 rss: 41Mb #64 pulse cov: 576 ft: 3641 exec/s: 0 rss: 50Mb #78 LOADED cov: 602 ft: 3936 exec/s: 0 rss: 88Mb #128 pulse cov: 611 ft: 3996 exec/s: 0 rss: 93Mb #180 DONE cov: 611 ft: 4016 exec/s: 0 rss: 155Mb MERGE-OUTER: succesfull in 1 attempt(s) MERGE-OUTER: the control file has 39741 bytes MERGE-OUTER: consumed 0Mb (37Mb rss) to parse the control file MERGE-OUTER: 9 new files with 80 new features added; 9 new coverage edges ``` Reviewers: hctim, morehouse Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits, kcc Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66030 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368617 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Complier warns that the result of a macro is undefined. The issue appears to be the use of !defined(SANITIZER_GO) when not in an #if context.