[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 137396] I would really like helgrind to work again...
From:       Julian Seward <jseward () acm ! org>
Date:       2007-10-10 13:10:45
Message-ID: 20071010131045.21896.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=137396         




------- Additional Comments From jseward acm org  2007-10-10 15:10 -------
> I see. I found one such potential deadlock in my app, but since it is in
> the logging class the number of potential threads and places where it is
> called is huge. Could you perhaps output which threads tried the
> potential deadlock and where ? Something like: Threads X and Y now
> locked in order L1 <stacktrace>, L2 <stacktrace> and it was previously
> locked in order L2 <stacktrace>, L1 <stacktrace> by Threads A and B.


I'll look into doing that; won't be this week though.  Maybe next week.

> Which leads me to the question: what kinds of synchronization points are
> handled correctly. [...]
> detected ? It obviously works for mutexes, but would it work for example
> for a condition variable, a sempahore or memory barrier ?


Mutexes and condition variables.  However it might be possible to extend it.
One way you could help is to send some small example programs using semaphores
and memory barriers, that demonstrate the problem.  Then I can consider if
it is possible to fix the tool to handle them.
[prev in list] [next in list] [prev in thread] [next in thread]