Dmitry Vyukov via llvm-dev
2015-Sep-08 07:15 UTC
[llvm-dev] [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.
Kostya Serebryany via llvm-dev
2015-Sep-08 17:19 UTC
[llvm-dev] [ThreadSanitizer] Get deadlocks working
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>
Vaivaswatha Nagaraj via llvm-dev
2015-Sep-10 01:16 UTC
[llvm-dev] [ThreadSanitizer] Get deadlocks working
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>