- User Since
- Dec 4 2015, 11:34 AM (77 w, 3 h)
Committed as rL303886
Wed, May 24
Factor out ThreadState location into helper function
Tue, May 23
Don't clobber thread state pointer in the tls shadow memory
This patch passes tests on its own, which is to be expected because it's currently a NFC (enabling darwin tls is blocked on this, so it hasn't been committed yet). However, it looks like this line causes many test failures, when combined with the patch to enable darwin tls:
Mon, May 22
Only remove checks on Darwin.
Fri, May 19
Yeah, I wasn't sure whether the preferred method here was to skip the block if Darwin or the current solution. There currently aren't any os-specific references in this file. Hopefully @dvyukov or @kubamracek have insight on the preferred way to do this.
Thu, May 18
Wed, May 17
Fix if condition equality
Tue, May 16
Check pthread_create result
Mon, May 15
Committed as r302898
Fri, May 12
Looks like XFAIL doesn't work, because they pass in LeakSanitizer-AddressSanitizer, and are just very flaky in LeakSanitizer-Standalone, so they end up XPASS-ing. I'll move them to UNSUPPORTED to fix the buildbot, and then we can go from there. I don't think it's reverting all of the lsan test suite for 2 flaky tests that I can't repro on 10.11 or 10.12.
I'm running the tests in a "repeat while test passes" loop, and neither of them are failing for me on 10.11 or 10.12.
Yeah, I xfail-ed those two tests for now to fix the buildbots, since I figure it's worth the test coverage (and this doesn't enable lsan by default outside the test suite anyway). Looking into the failures currently.
Thu, May 11
Remove accidental inclusion of extra files
Ah, okay, I didn't realize that aarch64 has a redzone as well (thread_get_register_pointer_values is only for x86). Will update.
Wed, May 10
Use static global to avoid use of cxa guard
Looks like we can't use the wrapper function for the static variable, because we don't always have access to the __cxa_guard functions. I reverted the commit for now, but I think the solution is to move the cached dyld header back to a static global var.
Tue, May 9
Use function to wrap dyld header static var and check for recurse error
Mon, May 8
Consolidate diff a bit
Fri, May 5
Wed, May 3
Tue, May 2
Move checks into cpp files
Yeah, that works too, just wasn't sure which way was preferred.
Mon, May 1
Fri, Apr 28
Apr 21 2017
nvm, looks like the source browser is now up-to-date
Oh wow, it is. If you look in the source-code browser, it appears to be running on out-of-date code (note the CHECK(0 && "unimplemented") in StopTheWorld): http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/ws/compiler-rt.src/lib/lsan/lsan_common_mac.cc
(this is the test run, by the way: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA_check/30443)
Well, looks like the zips that get downloaded are invalid zips, and extraction fails midway through. I've been looking into the actual failures, and it's actually a bit interesting. It's almost as if the tests are being run on a pretty old version of lsan, as pretty much all of the failures look like things that I've seen before and fixed (ie false-positive leaks from libxpc, etc).
The failures still don't repro with a clean build, but it looks like I can just download the buildbot state from here: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/ws/, so hopefully I can cherry-pick into that and see the failures.
Looks like this caused a large number of test failures. I'm a bit confused, since things worked fine locally, but I'm going to try to do a totally clean build with the buildbot config to see if I can repro.
Apr 20 2017
Refactor to address comments
Add test cases
Disable by default, but keep testing enabled
Apr 19 2017
I've been running this on some large internal FB programs, and I've found a couple issues with dyld memory which I think stem from the fact that sanitizer_procmaps_mac behaves differently than sanitizer_procmaps_linux. I'm also not very pleased with the performance, although I haven't dug into that too much yet.
Done in r300765
Update comment and add TODO
Yeah, it appears that sanitizer_procmaps_mac iterates using _dyld_get_image_vmaddr_slide, which will iterate over only images, as opposed to the vm_region_recurse_64 which iterates over all memory regions. The linux implementation just reads straight out of /proc/self/maps.
Remove extra function definition
Rework to only recurse memory regions once