https://bugs.kde.org/show_bug.cgi?id=439011
Bug ID: 439011
Summary: Unlocked non-locked lock possible FP with
std::unique_lock on std::timed_mutex
Product: valgrind
Version: unspecified
Platform: Ubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: helgrind
Assignee: jsew...@acm.org
Reporter: ionutf.oan...@yahoo.com
Target Milestone: ---
SUMMARY
Helgrind seems to have a False Positive on a simple
std::unique_lock<std::timed_mutex> variable that's used inside a shared library
Valgrind Version: 3.17.0
STEPS TO REPRODUCE
1. Create a dummy shared library that uses std::unique_lock<std::timed_mutex>
$ cat library.cpp
#include <mutex>
#include <chrono>
extern "C" void libraryFunc()
{
std::timed_mutex mutex;
std::unique_lock<std::timed_mutex> lock(mutex,
std::chrono::milliseconds(100));
}
# Note: I also tried with more C++ standards - c++17, c++2a - and the result
was the same
$ g++ -fPIC -shared -std=c++11 library.cpp -o libtest.so -pthread
2. Create a small executable which links against the above library
$ cat test.cpp
extern "C" void libraryFunc();
int main()
{
libraryFunc();
return 0;
}
$ g++ -fPIC test.cpp -std=c++11 -ltest -L. -o test -Wl,-rpath,'$ORIGIN'
3. Run the executable against helgrind
$ valgrind --tool=helgrind -s ./test
==2650== Thread #1 unlocked a not-locked lock at 0x1FFF000300
==2650== at 0x4844A75: mutex_unlock_WRK (hg_intercepts.c:1103)
==2650== by 0x484848D: pthread_mutex_unlock (hg_intercepts.c:1124)
==2650== by 0x4844AD7: mutex_unlock_WRK (hg_intercepts.c:1106)
==2650== by 0x484848D: pthread_mutex_unlock (hg_intercepts.c:1124)
==2650== by 0x48587EE: __gthread_mutex_unlock(pthread_mutex_t*)
(gthr-default.h:779)
==2650== by 0x485884B: std::timed_mutex::unlock() (mutex:219)
==2650== by 0x4858AFD: std::unique_lock<std::timed_mutex>::unlock()
(unique_lock.h:197)
==2650== by 0x48589A3: std::unique_lock<std::timed_mutex>::~unique_lock()
(unique_lock.h:106)
==2650== by 0x4858777: libraryFunc (library.cpp:7)
==2650== by 0x109155: main (test.cpp:5)
==2650== Lock at 0x1FFF000300 was first observed
==2650== at 0x484494C: mutex_timedlock_WRK (hg_intercepts.c:1060)
==2650== by 0x484847E: pthread_mutex_timedlock (hg_intercepts.c:1077)
==2650== by 0x48587BF: __gthread_mutex_timedlock(pthread_mutex_t*, timespec
const*) (gthr-default.h:769)
==2650== by 0x4858876: std::timed_mutex::_M_timedlock(timespec const&)
(mutex:231)
==2650== by 0x48591AA: bool
std::__timed_mutex_impl<std::timed_mutex>::_M_try_lock_until<std::chrono::duration<long,
std::ratio<1l, 1000000000l> >
>(std::chrono::time_point<std::chrono::_V2::system_clock,
std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&) (mutex:163)
==2650== by 0x4858DBF: bool
std::__timed_mutex_impl<std::timed_mutex>::_M_try_lock_until<std::chrono::_V2::steady_clock,
std::chrono::duration<long, std::ratio<1l, 1000000000l> >
>(std::chrono::time_point<std::chrono::_V2::steady_clock,
std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&) (mutex:171)
==2650== by 0x4858CBB: bool
std::__timed_mutex_impl<std::timed_mutex>::_M_try_lock_for<long, std::ratio<1l,
1000l> >(std::chrono::duration<long, std::ratio<1l, 1000l> > const&)
(mutex:147)
==2650== by 0x4858AB6: bool std::timed_mutex::try_lock_for<long,
std::ratio<1l, 1000l> >(std::chrono::duration<long, std::ratio<1l, 1000l> >
const&) (mutex:208)
==2650== by 0x4858970: std::unique_lock<std::timed_mutex>::unique_lock<long,
std::ratio<1l, 1000l> >(std::timed_mutex&, std::chrono::duration<long,
std::ratio<1l, 1000l> > const&) (unique_lock.h:100)
==2650== by 0x485876B: libraryFunc (library.cpp:7)
==2650== by 0x109155: main (test.cpp:5)
==2650== Address 0x1fff000300 is in a rw- anonymous segment
OBSERVED RESULT
Helgrind complains about unlocking a non-locked lock in std::unique_lock
destructor
EXPECTED RESULT
Helgrind should not report any problem
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
* DRD doesn't finds anything suspicious
* If the executable is linked against pthread as well (as the library is),
helgrind stops complaining.
* Tested with gcc 9.3 and clang 10
--
You are receiving this mail because:
You are watching all bug changes.
