std::lock_guard follows RAII for std::mutex. Invoking
std::lock_guard<std::mutex>::~lock_guard() makes unlock
call twice on underlying mutex. As per the API documentation
calling unlock from thread which does not own lock results in
undefined behaviour.
https://github.sec.samsung.net/RS7-IOTIVITY/IoTivity/pull/243
(cherry picked from commit
fc681e089d3bbbbd16f90ad05d53208f9a1602d1)
Change-Id: I9ef2f3eed0e4989a7d73ad1ab40a3bae0a01a11c
Signed-off-by: Harry <h.marappa@samsung.com>
Signed-off-by: Amit KS <amit.s12@samsung.com>
if ((dataCacheIns == cacheIDmap.end() && observeIns == observeCacheIDmap.end())
|| id == 0)
{
- lock.~lock_guard();
throw RCSInvalidParameterException {"[cancelResourceCache] CacheID is invaild"};
}
{
(observeIns->second).reset();
observeCacheIDmap.erase(id);
- lock.~lock_guard();
throw;
}
(observeIns->second).reset();