This is the mail archive of the
mailing list for the glibc project.
Re: Pthread mutex lock validator
I shall get back after resolving the copyright/license issues.
I hope the code is acceptable then.
On Thu, Apr 19, 2012 at 10:53 PM, Carlos O'Donell
> On Thu, Apr 19, 2012 at 12:52 PM, sanketh nalli <firstname.lastname@example.org> wrote:
>> 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
>> <email@example.com> wrote:
>>> On Tue, Apr 10, 2012 at 3:16 PM, sanketh nalli <firstname.lastname@example.org> 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 :
>>> > email@example.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
> As I mentioned above though, we can't accept your code unless you
> cleanup the copyright/license issues.
B.Tech Final year
Department of Information Technology
National Institute of Technology, Karnataka