- User Since
- Dec 6 2012, 2:31 AM (245 w, 22 h)
Tue, Aug 8
Tue, Aug 1
Sun, Jul 23
Thu, Jul 20
Jul 18 2017
Running ninja check-tsan with this change on linux/amd64 gives me:
This init sequence solves chicken and egg problem to large degree. This sequences served us well for years and I would feel nervous changing it even if no tests break on linux. I think it's better to do what asan does for dlsym (see AllocateFromLocalPool in asan sources), and I guess we need to move this code to sanitizer_common (not sure what msan does for this).
Jul 14 2017
Submitted as 308018.
Jul 12 2017
Jul 10 2017
Please go over other sanitizer APIs and check if we have any other i8/16/32 args. dfsan?
LGTM with a nit
LGTM with a nit
Jul 5 2017
Jun 22 2017
Evgenii, please take a look at actual pass changes.
I know, not the feedback you was looking for :)
Jun 13 2017
May 25 2017
I don't have time to figure out how to support Mac. Filed https://github.com/google/sanitizers/issues/816 so that this is not lost.
LGTM with a nit
May 24 2017
looks good to me
I am not certain about the Windows impact of this change
FWIW I've solved a similar problem in tcmalloc by trimming blocks either on left or on right. Namely, if heap grows up we trim on right; if heap grows down we trim on left. But I don't see how it is better than this solution.
May 23 2017
I think that's because we use _shadow_ memory to store pointer to ThreadState. See cur_thread in tsan_platform_mac.cc. We probably need to skip that slot or something.
I don't completely understand this. allocator_fork_no_hang.cc is broken and deserves deadlocking. Why are we trying to fix this program only under sanitizers rather than detecting and reporting the bug? Sanitizers are meant to be less forgiving than production environment. Why are we trying to conceal the bug?
May 22 2017
Yes, please do this only for Darwin. These things are extremely fragile, it's nice to be able to rely at least on some things. If we change it to if, it will silently break on other platforms and we will not notice.
You can either move some code to platform* files, or merely provide a flag in platform* files and use it here.
May 10 2017
Looks fine to me. Aleksey, do you want to take a look?
May 8 2017
May 5 2017
May 3 2017
I think this now provides a solid foundation for future extensions.
May 2 2017
One more thing: now that D31592 is landed, would you mind if we do the same for Tsan?
Dmitry, with your permission I'm going to update and commit this patch as it seems to be useful regardless of which way we support sanitizers on MMU-less platforms.
May 1 2017
Apr 29 2017
One last thing. Otherwise LGTM.
Apr 27 2017
LGTM on my side, but wait for Aleksey if he has more comments
Apr 26 2017
otherwise looks good
Apr 25 2017
Apr 23 2017
Apr 22 2017
Apr 21 2017
which will be checked in due time.
We have 3 potential users for the external API (Go, Java, races on fd, potentially more in future).
I don't like that we sprinkle swift-specific bits throughout the code when the external API was meant to be general enough to cover all such cases.
We have the special tag for swift, so it really seems to me that it should be the only swift-specific bit here and the rest must be handled by the external API on general basis. We have 3 potential users for the external API (Go, Java, races on fd, potentially more in future). So I would be really interested in making the external API general and flexible enough to support all of them, rather than later sprinkle Go/Java/fd/etc-specific bits throughout the code again later.
I am not completely follow motivation for this. Is it meant for user? Or for any automated tools?
For automated tools we already have SUMMARY line. User must be proficient enough to understand what happens. And in the end this is not specific to libc, and the guilty frame is not necessary the one just above libc. Consider a race in std::vector, it's probably not std::vector code that is guilty. And this extends just to any library, consider you have race in libfoo, but it's actually your code that misuses libfoo. We don't have enough info to provide precise signal. What we provide here is a weak, potentially incorrect signal.
If we actually plan to use such configuration, does it make sense to check header for corruption when we reallocate a block (in allocate)? That will give us at least some windows for UAF detection.