AMDG Rajeev Rao wrote:
When using shared_mutex class with shared_lock. I see the following behavior
boost::shared_lockboost::shared_mutex lock(m_mutex) ;
When running valgrind
==32255== LEAK SUMMARY: ==32255== definitely lost: 0 bytes in 0 blocks. ==32255== possibly lost: 0 bytes in 0 blocks. ==32255== still reachable: 8 bytes in 1 blocks. ==32255== suppressed: 0 bytes in 0 blocks.
However, if I change the code to boost::shared_lockboost::shared_mutex lock(m_mutex,boost::adopt_lock) ; then the valgrind report goes away.
This is undefined behavior. From the documentation shared_lock(Lockable & m,boost::adopt_lock_t) Precondition: The current thread owns an exclusive lock on m.
I understand that there are valid cases to expect reachable memory at exit Should this be expected in this case ?
Yes. This is not expected, and there is no obvious way to change it. In Christ, Steven Watanabe P.S. Please start a new thread instead of replying to an unrelated existing thread.