https://bugs.kde.org/show_bug.cgi?id=513598

Mark Wielaard <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Helgrind Assertion          |Helgrind should detect
                   |'lk->kind == LK_rdwr'       |locks without
                   |failed.                     |pthread_{rwlock,mutex}_dest
                   |                            |roy being called -
                   |                            |Assertion 'lk->kind ==
                   |                            |LK_rdwr' failed.

--- Comment #7 from Mark Wielaard <[email protected]> ---
(In reply to Aaron Merey from comment #6)
> I was able to figure this out. Helgrind got confused by a lock resource leak
> in the client program.  In this case a struct with rwlock and mutex fields
> is freed without pthread_{rwlock,mutex}_destroy being called on the locks. A
> new struct is then allocated such that an rwlock in the new struct is at the
> exact same address as a mutex from the freed struct. When
> pthread_rwlock_rdlock is called, helgrind still thinks there is a mutex at
> that address so it warns that a mutex is passed to an rwlock function.

Nice find.

> Helgrind should be able to detect this kind of lock resource leak and avoid
> the 'lk->kind == LK_rdwr' assert failure. Helgrind could also raise an error
> for locks that aren't destroyed when the process exits. I will work on a
> patch for this.

Thanks. Adding support for detecting reuse and/or freeing of the lock would
make sense.
The tricky part is that a mutex can be initialized not just through a
pthread_mutex_init call,
but also through a static initializer like PTHREAD_MUTEX_INITIALIZER, which
might be hard
to detect. Also at least with glibc pthread_mutex_destroy is kind of optional
because as the
manual says: "In the LinuxThreads implementation, no resources are associated
with mutex
objects, thus pthread_mutex_destroy() actually does nothing except checking
that the mutex
is unlocked." That doesn't mean you shouldn't try to add support for tracking
init/destroy.
But it might be tricky and you can expect that a lot of programs "leak" locks
because they
are never destroyed.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to