This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Pthread mutex lock validator
On Thu, Apr 19, 2012 at 12:52 PM, sanketh nalli <nalli.sanketh@gmail.com> wrote:
> Hi,
> Pardon me for an extremely delayed response.
> I shall keep up next time.
> I have answered your questions inline.
Please keep the list in the CC. Thank you.
> On Wed, Apr 11, 2012 at 1:14 AM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
>>
>> On Tue, Apr 10, 2012 at 3:16 PM, sanketh nalli <nalli.sanketh@gmail.com> wrote:
>> > As part of my senior thesis, I worked on writing a
>> > lock dependency validator for libpthread,
>> > which is similar to lockdep in Linux.
>> > My codes are available here :
>> > git@github.com:Sanketh/liblockdep.git
>> >
>> > I wish to contribute this to glibc/nptl.
>>
>> Thank you for contacting the community!
>>
>> We are always interested in more volunteers :-)
>>
>> Could you please talk about:
>>
>> * License and copyright?
>> ?- Contributing to glibc community requires that the copyright of
>> your contribution be given to the FSF.
>> ?- Who owns the license and copyright to the code?
>> ?- Your school?
>> ?- You?
>> ?- Are you able to sign a copyright assignment form for glibc?
>
>
> Well, no body has the copy rights to the code, not me nor my college.
> But, I borrowed the idea and some of the code from the Linux kernel.
> And the copyrights for that particular piece of code are with Ingo Molnar
> and Peter Zijlstra.
We would need the code to be appropriately licensed and copyright
handed over to the FSF to accept it as part of the project.
Unfortunately because you've seen the original code you can likely no
longer work on an independent version for glibc if we were to ask you
to rewrite it.
>> * Theory of operation?
>
> The lock-validator tracks the sequence of locks taken when the program
> is in execution. It plots a resource graph where the nodes are the locks.
> There is a directed edge from node i to node j, if lock j was taken after
> lock i.
>
> The validator runs BFS (breadth first search) over the graph every time
> a lock is requested. If any cycles are detected upon the acquisition of
> the lock, they are reported as deadlocks.
> Bugs are reported even if the current locking scenario does not cause
> any deadlock at this point.
> I.e. if anytime in the past two locks were taken in a different order,
> even if it happened for another task, even if those were different
> locks (but of the same class as this lock), this code will detect it.
>
> The validator also checks for recursive locks i.e. lock taken twice
> and lock release bug i.e a lock being released without ever being held.
That's a good description thanks.
>> * Current results against glibc trunk?
>>
> i am not sure what this means. Please elaborate.
Have you tried using your lock dependency validator with a build of
glibc trunk? Did you find any bugs?
>> * Do you plan to stay involved with glibc and maintain this test?
>
> Yes... I plan to stay involved and merge this in the main stream library.
... and after that? Are you interested in maintaining the code?
You *could* use LD_PRELOAD and library auditing to track all lock
operations, and use internal knowledge of the lock layout to run your
algorithm.
As I mentioned above though, we can't accept your code unless you
cleanup the copyright/license issues.
Cheers,
Carlos.