<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 6:10 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jason,<br>
<br>
I have a few additional points:<br>
<br>
1. It works on glibc but not in bionic because glibc calls internal<br>
allocation functions while bionic calls malloc/free, which get<br>
instrumented when the thread is being destroyed. Calling bionic_malloc<br>
on those cases should be enough to remove the problem altogether, but<br>
we should not call bionic_malloc everywhere, since we want all other<br>
calls to be instrumented and we don't want user facing behaviour to<br>
change.<br>
<br></blockquote><div><br></div><div>The calls that are changed would be purely bionic-to-bionic calls of XXXX() (XXXX() being malloc() or whatever else). There would be no user noticeable diffferences.  If XXXX() is called by a user routine, it would still be intercepted.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. The changes to Android should be made in the implementation, not in<br>
the header files. We're trying to avoid include nightmares and<br>
pre-processor race conditions, as well as protecting users from<br>
implementation details.<br></blockquote><div><br></div><div>???? There are no nightmares here. Of what do you speak?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Google will prioritise pthread_barrier and other functionality that<br>
helps TSAN works with bionic without the need for the TLS workaround<br>
in compiler-rt. They'll also set up some internal bots to make sure we<br>
test those things from now on.<br>
<br></blockquote><div><br></div><div>Sure. That sounds fine.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
cheers,<br>
--renato<br>
<div class="HOEnZb"><div class="h5"><br>
On 24 September 2015 at 11:18, Jason Kim <<a href="mailto:jasonk@codeaurora.org">jasonk@codeaurora.org</a>> wrote:<br>
> Hi everyone.<br>
><br>
> Thanks to everyone for taking the time to meet yesterday. I think it was<br>
> very productive!<br>
><br>
> I am writing to keep a "minutes" of the meet, as I remember them.<br>
><br>
> Action Items:<br>
><br>
> Jasonk:  split up bionic patch to explicitly replace CPP macros with actual<br>
> calls, one file at a time.<br>
> Google/Android: pthread_barrier interface in bionic<br>
> Enh:  1 paragraph to explain "namespacing" in bionic?? (in case we need to<br>
> reconsider macro replacement again?)<br>
><br>
> Some technical notes/explanations that possibly weren't made clear at the<br>
> meeting.<br>
><br>
> The current compller-rt patch (on phabricator)  is already a pretty minimal<br>
> set. The only real bit of actual functionality (other than the<br>
> infrastructure bits to enable TSAN on android/aarch64) is the TLS<br>
> workaround.<br>
><br>
> i.e. the major pieces for my patch to compiler-rt are:<br>
><br>
> infrastructure (new definitions, cmake changes etc..)<br>
> TLS workaround<br>
> pthread_barrier-like interface for tests<br>
> disabling of some tests on android-aarch64<br>
><br>
> My current hypothesis is that the 120 tests (out of 200 or so)  that are<br>
> failing are due the behavioral mismatch of my "quick hack" to enable<br>
> barrier-like behavior on android. Assuming that Google's implementation of<br>
> the barrier interface on android/aarch64 is a better fit with linux-x86_64,<br>
> this will hopefully result in more tests passing.<br>
><br>
> Very important info regarding why __bionic_XXX() replacement for calls to<br>
> XXX() will most likely need to be "global" (within bionic) in most cases:<br>
><br>
> deadlocks, crashes in TSAN were all due to unexpected interceptions WHILE a<br>
> call was already being intercepted by TSAN.<br>
> The most obvious TSAN-only workaround is to ignore interceptions when this<br>
> is taking place. This works for two threads, but   does not scale to more<br>
> threads without the danger of TSAN missing events.<br>
> Any unexpected nested call chains in bionic that TSAN currently intercepts<br>
> will either need custom coding in TSAN to explicitly handle (for all<br>
> possible cases in which such call chains can occur), OR replace those calls<br>
> in bionic with non-interceptible ones. The former will obviously add much<br>
> more complexity to TSAN (to wit, additional testing failure vulnerability),<br>
> while the latter will mean more (mechanical) changes to BIONIC. Currently,<br>
> my thinking is that the latter, (being mechanical in nature) is preferable.<br>
> To ENH: The same holds for calls to tcgetattr() --> ioctl(), and isatty() -><br>
> tcgetattr() --> ioctl() call chains. TSAN intercepts  tcgetattr() and<br>
> ioctl(), and is not expecting recursive interceptions during them. Its not<br>
> at all clear how to handle this within TSAN, especially among multiple<br>
> threads. Even if a logic can be worked out, it's fundamentally much clearer<br>
> to simply disallow such interceptions to occur.<br>
><br>
> Things that might require future discussion:<br>
><br>
> need a build-bot/test bot on <a href="http://labs.llvm.org" rel="noreferrer" target="_blank">labs.llvm.org</a> for android-bionic-aarch64-tsan<br>
> tests to prevent insanity inducing regressions :-)<br>
><br>
> Thanks for reading!<br>
><br>
> -Jason<br>
><br>
><br>
><br>
><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
You received this message because you are subscribed to the Google Groups "thread-sanitizer" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:thread-sanitizer%2Bunsubscribe@googlegroups.com">thread-sanitizer+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/optout</a>.<br>
</div></div></blockquote></div><br></div></div>