Fwd: Pthread mutex lock validator

sanketh nalli nalli.sanketh@gmail.com
Thu Apr 19 17:06:00 GMT 2012


Hi,

LD_PRELOAD was the first idea that came to me when
I started with this project. But i soon, realised that it may not
be possible.
The task of spawning threads and servicing lock requests
is delegated to libpthread.
And the custom pthread_mutex_t has to store
some extra information to help detect recursive locking,
(that is what i figured by looking at the Linux Kernel
which does this.)

But please do tell me if there were some way to over come these.
I really like the idea of LD_PRELOAD.

On Wed, Apr 11, 2012 at 1:25 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Carlos O'Donell 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.
> [...]
>> * Do you plan to stay involved with glibc
>
> The idea _almost_ works as something that could be used as an
> LD_PRELOAD library (meaning: no need to rebuild your app to test it!),
> but unfortunately the library stores some extra per-thread information
> in its custom pthread_mutex_t struct.
>
> Is that a fundamental limitation, or could it be fixed?  If the latter
> is the case, I think this could be a pleasant tool to use, without
> requiring any change to glibc/nptl.  See fakeroot for an example of
> how this can work.
>
> Hope that helps,
> Jonathan



--
Regards

Sanketh Nalli
B.Tech Final year
Department of Information Technology
National Institute of Technology, Karnataka


-- 
Regards

Sanketh Nalli
B.Tech Final year
Department of Information Technology
National Institute of Technology, Karnataka



More information about the Libc-help mailing list