#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007f4a1c0afbb5 in __GI___pthread_mutex_lock (mutex=0x1fe7328) at ../nptl/pthread_mutex_lock.c:80
#2 0x00007f4a1b5a5899 in uv_mutex_lock () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#3 0x000000000095d8fc in cass::Session::refresh_metadata_callback(CassFuture_*, void*) ()
#4 0x000000000094bb3c in cass::Future::internal_set(cass::ScopedLock<cass::Mutex>&) ()
#5 0x00000000009eebcc in cass::RequestHandler::set_error(CassError_, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#6 0x0000000000957c43 in cass::Session::execute(cass::SharedRefPtr<cass::RequestHandler> const&) ()
#7 0x000000000095dddd in cass::Session::on_refresh_metadata(cass::PeriodicTask*) ()
#8 0x00007f4a1b5969b4 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#9 0x00007f4a1c0ad4a4 in start_thread (arg=0x7f49f9ffe700) at pthread_create.c:456
In the Session::on_refresh_metadata(), we already take the lock on refresh_metadata_futuremutex.
We shouldn't take lock on refresh_metadata_futuremutex again in Session::refresh_metadata_callback
Here is sample stack trace:
In the Session::on_refresh_metadata(), we already take the lock on refresh_metadata_futuremutex. We shouldn't take lock on refresh_metadata_futuremutex again in Session::refresh_metadata_callback