- User Since
- Dec 4 2015, 11:34 AM (110 w, 4 d)
Sat, Jan 13
Fri, Jan 12
Thu, Jan 11
SymbolVendor::FindFunctions will lazily parse functions from the debug info and populate things inside the module, so the lock is required.
I think a better option would be to remove that lock and if it is needed then lock it just for the calls where it necessary. The fact that SymbolVendor locks a mutex inside a Module feels like a pretty bad layering violation for me what can cause many other deadlocks so it would be nice to fix that instead of hacking it around here.
Wed, Jan 10
It's definitely possible to re-design the lock holding in such a way that we can keep this locked, but I don't want to go through all the work to do that if there isn't any added value to doing so.
Actually I don't think even that is racy, because we just get a pointer to the const char *, which is immutable anyway.
I guess the question is whether we expect that someone will do something like change the module's filepath while we're printing a log message with that filepath in it.
Tue, Jan 9
I think it would be preferable to define this as a separate constant (perhaps kSanitizerVmMemoryOsAllocOnce, like @kubamracek suggested), which is set to VM_MEMORY_OS_ALLOC_ONCE if defined, and some other value (that 73 perhaps?) otherwise. Makes it clear that the constant used by the code isn't necessarily the same as the one set by the system.
Mon, Jan 8
Abandoning in favor of D41706
Tue, Jan 2
Verified that this fixes my DESTDIR build of standalone compiler-rt.
That patch fixes our build for me.
Yeah, if I try to use an empty CMAKE_INSTALL_PATH for compiler-rt, I end up with:
ping (particularly looking for input from @beanz)
Tue, Dec 19
Nov 30 2017
Nov 29 2017
Seems fine to me, and since nobody else has had any issue with it, I'll accept.
Nov 16 2017
Nov 15 2017
Nov 14 2017
Nov 10 2017
An alternative could be to just disable the build of LSan on OS X < 10.9 (or even 10.11)
Because macOS changes quite a bit from version to version, we (or at least I) don't have strong plans to support LSan outside of 10.11+. Not sure what darwin used to store singleton kernel allocations before this page was introduced, but I assume that just not handling those allocations will lead to a ton of false positives. I'm inclined to let this fail on old versions unless there's someone willing to do the work to make sure they're properly supported. cc @kubamracek
Nov 9 2017
Oct 23 2017
Awesome, good to know. Thanks!
Oct 21 2017
Oct 19 2017
On platforms where BOOL == signed char, is it actually undefined behavior (or is it just bad programming practice) to store a value other than 0 or 1 in your BOOL? I can't find any language specs suggesting that it is, and given that it's just a typedef for a signed char, I don't see why it would be.
Oct 16 2017
(for posterity, the build is not failing anymore with this patch committed)
Oct 10 2017
@qcolombet - Can you keep an eye on the internal apple builders and let me know if this doesn't fix them? I'll be out of the town the rest of the week though, so I probably won't be able to do much until Monday.
Improve warning messages
Used here: https://reviews.llvm.org/D38703
Clang change here: reviews.llvm.org/D38741
I'm going to be on vacation starting tomorrow (oct 11), and this seems like a pretty unoffensive change to me, so if I don't hear anything positive or negative by the end of the day, I'll commit this to fix the green bootstrapped builders.
I'll upload the clang host_cxx patch shortly, but this shouldn't be blocked on that (since it handles the undefined case).
Fairly certain that if this is 10.11-specific, it's either a leak in libxar, or a bug in LeakSanitizer. It doesn't appear to be a leak in objdump itself (particularly when looking at the stack, which has a dispatch_once call in it)
Oct 9 2017
Fix a couple python issues
Fixing a couple issues.
I got this failure to reproduce locally on my macOS 10.11 VM, but it's probably still worth disabling the leak checking on this test to fix the buildbots until I can diagnose the issue.
Oh interesting. I tried using PWD=/, but I didn't try actually cd-ing into that directory. I'll try that - thanks!
Looks good to me
I'm running into some issues with using a precompiled binary + object file here. For some reason, the debug info contains an absolute path to the object file instead of a relative path, so dsymutil will fail because it's looking for a path that doesn't exist (ie a path on my local machine). This is true even if I use -fdebug-compilation-dir (it updates the debug info in the IR, but doesn't change where dsymutil looks for the object file). I also tried -add_ast_path, which works as a hacky workaround because it will search the relative path in addition to the absolute path, but that seems like a bad solution.
Oct 6 2017
Use precompiled binary with IR as a comment to allow testing on linux
Move to x86 test dir
Delete copy constructor (which implicitly deletes move constructor), and
Oct 5 2017
They fail with:
while processing dwarf streamer init
error: : error: unable to get target for 'x86_64-apple-darwin', see --version and --triple.
Weirdly, appending .macho.x86_64 fixed the armv7/thumbv7 buildbots, but not aarch64. Will try to diagnose.
Don't call deallocation routines on null xar objects
Xar -> ScopedXar
I think that postfixing the binary name with ".macho.x86_64" will work, that seems to be what the other tests do, although I can't seem to find a lit config relating to that.