llvm dev - Sep 2015 - [ThreadSanitizer] Get deadlocks working

+thread-sanitizer mailing list

On Mon, Sep 7, 2015 at 6:41 PM, Vaivaswatha Nagaraj <vn at
compilertree.com> wrote:
> Hi,
>
> I am interested in understand the compiler-rt thread sanitizer tool and
have
> recently started experimenting with it. In particular, I'm interested
in the
> deadlock detector.
>
> I see that deadlock detection currently don't work. (I tried with a few
> simple deadlocks, as well as the test case "must_deadlock.cc"
that is in the
> test-suite). I understand from the comments that this is because the real
> pthread_mutex_lock() is called before the handler (MutexLock()) in tsan.
>
> 1. Is there any particular reason that this interceptor is designed this
> way? Can there be a callback prior to calling the real pthread_mutex_lock()
> that can, for example, detect deadlocks?
> 2. Upon debugging a simple test case, I see that there is a worker thread
> that is created. Can this worker not check for the deadlock when the actual
> threads are deadlocked.
Hello Vaivaswatha,

Yes, tsan currently detects only _potential_ deadlocks. On actual
deadlocks it deadlocks as well.
This is just not implemented yet. Yes, mutex callback needs to be
split into pre and post parts. The deadlock detector already has
separate callbacks for these events, it is just a matter of threading
these callbacks through tsan code.
You can look at the standalone deadlock detector in
lib/tsan/dd/dd_interceptors.cc, it does it correctly.

-- 
Dmitry Vyukov, Software Engineer, dvyukov at google.com
Google Germany GmbH, Dienerstraße 12, 80331, München
Geschäftsführer: Graham Law, Christine Elizabeth Flores
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
sind, leiten Sie diese bitte nicht weiter, informieren Sie den
Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
This e-mail is confidential. If you are not the right addressee please
do not forward it, please inform the sender, and please erase this
e-mail including any attachments. Thanks.

On Tue, Sep 8, 2015 at 12:15 AM, Dmitry Vyukov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +thread-sanitizer mailing list
>
> On Mon, Sep 7, 2015 at 6:41 PM, Vaivaswatha Nagaraj <vn at
compilertree.com>
> wrote:
> > Hi,
> >
> > I am interested in understand the compiler-rt thread sanitizer tool
and
> have
> > recently started experimenting with it. In particular, I'm
interested in
> the
> > deadlock detector.
> >
> > I see that deadlock detection currently don't work. (I tried with
a few
> > simple deadlocks, as well as the test case
"must_deadlock.cc" that is in
> the
> > test-suite). I understand from the comments that this is because the
real
> > pthread_mutex_lock() is called before the handler (MutexLock()) in
tsan.
> >
> > 1. Is there any particular reason that this interceptor is designed
this
> > way? Can there be a callback prior to calling the real
> pthread_mutex_lock()
> > that can, for example, detect deadlocks?
> > 2. Upon debugging a simple test case, I see that there is a worker
thread
> > that is created. Can this worker not check for the deadlock when the
> actual
> > threads are deadlocked.
>
> Hello Vaivaswatha,
>
> Yes, tsan currently detects only _potential_ deadlocks. On actual
> deadlocks it deadlocks as well.
> This is just not implemented yet.

Correct, I just did not have time to implement this.
In practice this is not the most important thing to have because
if the deadlock has actually happened in a test it is easy to find.
The potential deadlocks are more important.
Yet I fully agree this needs to be implemented.

--kcc


> Yes, mutex callback needs to be
> split into pre and post parts. The deadlock detector already has
> separate callbacks for these events, it is just a matter of threading
> these callbacks through tsan code.
> You can look at the standalone deadlock detector in
> lib/tsan/dd/dd_interceptors.cc, it does it correctly.
>
> --
> Dmitry Vyukov, Software Engineer, dvyukov at google.com
> Google Germany GmbH, Dienerstraße 12, 80331, München
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
> sind, leiten Sie diese bitte nicht weiter, informieren Sie den
> Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
> This e-mail is confidential. If you are not the right addressee please
> do not forward it, please inform the sender, and please erase this
> e-mail including any attachments. Thanks.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/a57676d2/attachment.html>

Thanks Kostya and Dmiitry, that was helpful.

  - Vaivaswatha

On Tue, Sep 8, 2015 at 10:49 PM, Kostya Serebryany <kcc at google.com>
wrote:
>
>
> On Tue, Sep 8, 2015 at 12:15 AM, Dmitry Vyukov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> +thread-sanitizer mailing list
>>
>> On Mon, Sep 7, 2015 at 6:41 PM, Vaivaswatha Nagaraj <vn at
compilertree.com>
>> wrote:
>> > Hi,
>> >
>> > I am interested in understand the compiler-rt thread sanitizer
tool and
>> have
>> > recently started experimenting with it. In particular, I'm
interested
>> in the
>> > deadlock detector.
>> >
>> > I see that deadlock detection currently don't work. (I tried
with a few
>> > simple deadlocks, as well as the test case
"must_deadlock.cc" that is
>> in the
>> > test-suite). I understand from the comments that this is because
the
>> real
>> > pthread_mutex_lock() is called before the handler (MutexLock()) in
tsan.
>> >
>> > 1. Is there any particular reason that this interceptor is
designed this
>> > way? Can there be a callback prior to calling the real
>> pthread_mutex_lock()
>> > that can, for example, detect deadlocks?
>> > 2. Upon debugging a simple test case, I see that there is a worker
>> thread
>> > that is created. Can this worker not check for the deadlock when
the
>> actual
>> > threads are deadlocked.
>>
>> Hello Vaivaswatha,
>>
>> Yes, tsan currently detects only _potential_ deadlocks. On actual
>> deadlocks it deadlocks as well.
>> This is just not implemented yet.
>
>
> Correct, I just did not have time to implement this.
> In practice this is not the most important thing to have because
> if the deadlock has actually happened in a test it is easy to find.
> The potential deadlocks are more important.
> Yet I fully agree this needs to be implemented.
>
> --kcc
>
>
>
>> Yes, mutex callback needs to be
>> split into pre and post parts. The deadlock detector already has
>> separate callbacks for these events, it is just a matter of threading
>> these callbacks through tsan code.
>> You can look at the standalone deadlock detector in
>> lib/tsan/dd/dd_interceptors.cc, it does it correctly.
>>
>> --
>> Dmitry Vyukov, Software Engineer, dvyukov at google.com
>> Google Germany GmbH, Dienerstraße 12, 80331, München
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
>> sind, leiten Sie diese bitte nicht weiter, informieren Sie den
>> Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
>> This e-mail is confidential. If you are not the right addressee please
>> do not forward it, please inform the sender, and please erase this
>> e-mail including any attachments. Thanks.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150910/fb39095b/attachment.html>