https://bugs.kde.org/show_bug.cgi?id=379630
Ivo Raisr <iv...@ivosh.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
--- Comment #5 from Ivo Raisr <iv...@ivosh.net> ---
Yes, compilation options make a huge difference.
I can reproduce the problem now.
DRD with '--trace-mutex=yes' reports this:
...
m1=0xffefffc00, m2=0xffefffc28
==23335== [1] mutex_trylock mutex 0xffefffc00 rc 0 owner 0
==23335== [1] post_mutex_lock mutex 0xffefffc00 rc 0 owner 0
==23335== [1] mutex_trylock mutex 0xffefffc28 rc 0 owner 0
==23335== [1] post_mutex_lock mutex 0xffefffc28 rc 0 owner 0
==23335== [1] mutex_unlock mutex 0xffefffc28 rc 1
==23335== [1] mutex_unlock mutex 0xffefffc00 rc 1
m2=0xffefffc00, m1=0xffefffc28
==23335== [1] mutex_trylock mutex 0xffefffc28 rc 0 owner 1
==23335== [1] post_mutex_lock mutex 0xffefffc28 rc 0 owner 1
==23335== [1] mutex_trylock mutex 0xffefffc00 rc 0 owner 1
==23335== [1] post_mutex_lock mutex 0xffefffc00 rc 0 owner 1
==23335== [1] mutex_unlock mutex 0xffefffc00 rc 1
==23335== [1] mutex_unlock mutex 0xffefffc28 rc 1
And Helgrind built with "SHOW_EVENTS 1" reports this:
m1=0xffefffc10, m2=0xffefffc38
evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC10)
evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC10)
evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC38)
evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC38)
evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC38)
evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC38)
evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC10)
evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC10)
m2=0xffefffc10, m1=0xffefffc38
evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC38)
evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC38)
evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC10)
evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC10)
<error about lock order violation here>
evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC10)
evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC10)
evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC38)
evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC38)
So both tools correctly detect mutex lock and unlock.
DRD does not report lock order violation, although it could have.
As regards detecting when mutex is allocated or not. The reproducer
unfortunately does not invoke none of pthread_mutex_init() or
pthread_mutex_destroy().
If you disassemble the resulting binary, you'll see calls to
gthread_mutex_lock() and gthread_mutex_unlock(). However no calls to init or
destroy - they are implicit.
At this point I think you need to teach your program to annotate for this.
See Valgrind manual [1] and also these hints [2].
[1] http://valgrind.org/docs/manual/drd-manual.html#drd-manual.C++11
[2] http://valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use
--
You are receiving this mail because:
You are watching all bug changes.
