User Details
- User Since
- Apr 16 2014, 10:32 PM (353 w, 1 d)
Dec 4 2018
So I am not sure if there is any value in using aliases without indicators.
Dec 3 2018
I think this should be fine, aliases don't need names at all.
Hm, I'd rather separate private aliases and odr indicators because they are separate (although connected) features:
Sep 5 2018
lgtm
Oh, sorry, forgot about this :(. Please rebase and upload new version.
BTW, please don't forget to add 'llvm-commits' to subscribers so your patch will be visible in ML.
Aug 13 2018
Looks good. Will commit this tomorrow if nobody objects.
Aug 2 2018
Looks good, but let's wait for code owners to accept this as well.
Mar 6 2018
Now, the cfg for this example:
void test_for_implicit_scope() { for (A a; A b = a;) A c; }
looks like this:
Rebased and updated. Fix the issue with ordering between ScopeEnds and implicit destructors.
Feb 20 2018
Feb 1 2018
Fix scope ends order (as discussed above) and adjust a testcase.
Jan 31 2018
Jan 29 2018
Actually upload the files.
Hi Artem,
Jan 23 2018
Rebased and ping.
Jan 19 2018
Jan 17 2018
Some code cleanup + updated test case.
Jan 16 2018
Hi Devin,
Dec 18 2017
Hi, I've committed this on behalf of Denis. @denis13 Will ping you if some buildbots complain about this change.
Nov 30 2017
Adding maintainers + some comments.
Sep 19 2017
Aug 24 2017
Ping^4
Aug 16 2017
Ping^3
Aug 9 2017
Rebased and ping.
Aug 2 2017
Jul 28 2017
Updated some comments. Could someone take a look please?
Jul 24 2017
Rebased and removed a bunch of stale changes. Also added a check for goto's: if we see GotoStmt and have cfg-scopes == true, make badCFG = true and retry without scopes enabled. This check will be removed once GotoStmt will become supported.
Jul 13 2017
Updating the diff. I've dropped SwitchStmt support, let's implement in separately as well as GotoStmt.
Jul 10 2017
Hi Artem, I'm sorry for a long delay (nasty corporate issues).
Jun 26 2017
Jun 23 2017
So, updating the diff. This is still a very experimental version and any feedback would be greatly appreciated.
Current patch should support basic {If, While, For, Compound, Switch}Stmts as well as their interactions with {Break, Continue, Return}Stmts.
GotoStmt and CXXForRangeStmt are not supported at this moment.
Jun 22 2017
unless someone has objections (@bshastry ?) I'll commandeer this revision and post updated patch shortly (it still needs some polishing though).
Jun 14 2017
Jun 13 2017
Jun 8 2017
Jun 7 2017
Jun 6 2017
Please add a testcase. For me, following commands work:
$ cat foo.c
#include <stdlib.h>
Jun 5 2017
Jun 2 2017
Jun 1 2017
Let me share more background.
The problem occurs in such rare cases when we have one instrumented library and uninstrumented binary with lots of dependencies from other (uninstrumented) shared libs. In this case we can use LD_PRELOAD trick to preload shared ASan runtime to uninstrumented binary, but since rtld actually doesn't specify order of constructors execution, we can end up with overflow in static alloc_memory_for_dlsym pool if some constructor has malloc with some big size and this constructor is called before __asan_init. The right solution would be just build the executable with ASan, but unfortunately sometimes developers can't do this.
May 31 2017
Please add a testcase (you can take it from Vedant's patch in PR).
May 30 2017
Rebased. Gentle reminder.
May 24 2017
Removing TSan part. The attached testcase still hangs with TSan, but since locking allocator is problematic let's leave TSan alone.
May 23 2017
Addressing Dmitry's comments.
Updating. Reproduced the deadlock with TSan and LSan on adjusted testcase. Adding Dmitry since the patch now affects TSan code as well.
May 22 2017
Updating. Lock allocator on fork for {A, M, T}San and moving testcase to sanitizer_common. I've also managed to reproduce the deadlock with MSan, but still not with TSan.
May 19 2017
Updating. When adapting test/msan/fork.cc for ASan I've noticed that deadlock can also happen if the whole allocator is locked when we calling fork. Corresponding backtrace looks like this:
#0 atomic_exchange<__sanitizer::atomic_uint32_t> () at /home/max/src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h:68 #1 Lock () at /home/max/src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:541 #2 0x000000000041e9f9 in GenericScopedLock () at /home/max/src/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:187 #3 GetFromAllocator () at /home/max/src/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:134 #4 0x000000000041e99b in Refill () at /home/max/src/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_local_cache.h:108 #5 0x000000000041e550 in Allocate () at /home/max/src/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_local_cache.h:50 #6 0x000000000041e443 in Allocate () at /home/max/src/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:68 #7 0x000000000041b6cb in Allocate () at /home/max/src/llvm/projects/compiler-rt/lib/asan/asan_allocator.cc:407 #8 0x00000000004b9148 in __interceptor_malloc () at /home/max/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67 #9 0x00000000004e878d in child () at fork.cc:47 #10 0x00000000004e8968 in test () at fork.cc:67 #11 0x00000000004e8a38 in main () at fork.cc:78
Thus we need to lock allocator as well.
May 18 2017
May 2 2017
Add guards against old Glibc versions to testcase.
Apr 27 2017
Remove INIT_MCHECK_MPROBE.
Add mcheck_pedantic.
Remove enum.
Apr 17 2017
Apr 13 2017
Thanks! Watching for buildbots...
Apr 12 2017
lgtm
Apr 11 2017
Apr 10 2017
Add armeb and thumbeb for completeness.
Just curious, does anyone use sanitizers in these targets? I see no public buildbots for armeb and thumbeb. Anyway, not a big deal of course.
Apr 7 2017
Also check for thumb.
Apr 6 2017
Apr 5 2017
Apr 4 2017
Updating according to Aleksey's comments.
Apr 3 2017
Turned out I was wrong again. Looking to verbose log more carefully, one can see that segfault happens when GetRegistersAndSP fails with errno 3 (ESRCH):
==13657==Attached to thread 14860. ==13657==Attached to thread 14868. ==13657==Attached to thread 13349. ==13657==Attached to thread 13357. ==13657==Could not get registers from thread 13349 (errno 3). ==13657==Unable to get registers from thread 13349. Tracer caught signal 11: addr=0x7ff4b259b000 pc=0x4239d0 sp=0x7ff4b1d99d90 ==13657==Process memory map follows: ... 0x7ff4b1d9b000-0x7ff4b259b000 0x000000000003 (rw) 0x7ff4b259b000-0x7ff4b259c000 0x000000000000 ... ==13657==End of process memory map. ==13657==Detached from thread 14860. ==13657==Detached from thread 14868. ==13657==Could not detach from thread 13349 (errno 3). ==13657==Detached from thread 13357. ==14860==LeakSanitizer has encountered a fatal error. ==14860==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 ==14860==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
Although LSan successfully attached to thread 13349, it seems that this thread was killed by concurrent SIGKILL signal. Thus stack boundaries extracted by GetRegistersAndSP are already invalid and we access "bad" memory (guard page in this case).
According to ptrace manual, when user tries to get information from ptrace stopped thread he should always be ready to handle ESRCH error:
Rebased. Ping.
Mar 30 2017
Changed flag name.
Mar 29 2017
Looks good, thank you.
Mar 28 2017
Could you elaborate, what kind of issue are you trying to solve? LSan in ASan seems to work fine on x86 Linux, it looks like a wrong idea to disable tests there.
Mar 27 2017
Rebased. Gentle reminder.
Mar 23 2017
Mar 22 2017
Mar 21 2017
After more debugging it seems that the issue is even more complicated.
Tracer caught signal 11: addr=0x7fb108da4000 pc=0x423990 sp=0x7fb135ffed90 ==9109==Process memory map follows: 0x000000400000-0x000000441000 /tmp/a.out 0x000000000005 0x000000641000-0x000000642000 /tmp/a.out 0x000000000001 0x000000642000-0x000000645000 /tmp/a.out 0x000000000003 ... 0x7fb1085a4000-**0x7fb108da4000** rw (0x000000000003)
The faulty address looks fine (addressable and accessible), but the problem seems to be pretty similar to that we saw in fast unwinder some time ago (fixed by Evgeniy with https://reviews.llvm.org/rL219683).
Possible explanation (that we considered when debugging segfault in unwinder) looks like this:
- Kernel maps stacks from higher addresses to lower (MAP_GROWSDOWN flag in mmap syscall).
- Kernel maps stacks non-atomically (i.e not all ulilmit amount of stack memory become addressable simultaneously, lower pages become available a little bit later than higher).
- If we make access to *stack_top (== stack_bot - ulimit) before kernel actually mapped all ulimit range, we'll have segfault.
Mar 20 2017
Ping.
Mar 17 2017
Gentle ping. Is there any chance that LSan for ARM will be accepted?