Opened 6 years ago
Last modified 4 years ago
#12659 new Bugs
Deadlocked with boost::interprocess::managed_mapped_file find
Reported by: | Owned by: | Ion Gaztañaga | |
---|---|---|---|
Milestone: | To Be Determined | Component: | interprocess |
Version: | Boost 1.61.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Scenario : I have a existing file which at first is opened & loaded using
m_file.reset(new boost::interprocess::managed_mapped_file(boost::interprocess::open_or_create, file_name.c_str(), m_size));
then I am using find member function
Type *vect = m_file->find<Type>(key).first;
Here my code halts(deadlock).
boost::interprocess::ipcdetail::posix_recursive_mutex::lock (this=0x7ffff572d070) at /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90 90 if (pthread_mutex_lock(&m_mut) != 0) (gdb) p m_mut $1 = {__data = {__lock = 2, __count = 1, __owner = **16792**, __nusers = 1, __kind = 129, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\001\000\000\000\230A\000\000\001\000\000\000\201", '\000' <repeats 22 times>, __align = 4294967298} (gdb) info threads all 4 Thread 0x7ffff6af0700 (LWP 23305) 0x00000038dceac6aa in times () from /lib64/libc.so.6 3 Thread 0x7ffff75dd700 (LWP 23304) 0x00000038dd20b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x7ffff7fde700 (LWP 23303) 0x00000038dd20eca3 in recvfrom () from /lib64/libpthread.so.0 * 1 Thread 0x7ffff7fe27e0 (LWP 23300) boost::interprocess::ipcdetail::posix_recursive_mutex::lock (this=0x7ffff572d070) at /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90
If you see here onwer is 16792, but I don't see any such thread.
Some more info.
p *mp_header ..... static PayloadPerAllocation = <optimized out>, m_header = {<boost::interprocess::interprocess_recursive_mutex> = {mutex = {m_mut = { __data = {__lock = 2, __count = 1, __owner = 16792, __nusers = 1, __kind = 129, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\001\000\000\000\230A\000\000\001\000\000\000\201", '\000' <repeats 22 times>, __align = 4294967298}}}, m_named_index = .....
previous mutex informations are still stored.
Change History (3)
comment:1 by , 6 years ago
Component: | None → interprocess |
---|---|
Owner: | set to |
follow-up: 3 comment:2 by , 6 years ago
comment:3 by , 4 years ago
Replying to Ion Gaztañaga:
I can't reproduce the problem, could you provide a small compilable test case?
I am suffering from this problem too.
The code halts at the lock.
(gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fcb740 (LWP 15189) "test_mmap" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 (gdb) bt #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007ffff7bc3e42 in __GI___pthread_mutex_lock (mutex=0x7ffff6df0070) at ../nptl/pthread_mutex_lock.c:115 #2 0x000000000040286f in boost::interprocess::ipcdetail::posix_recursive_mutex::lock (this=0x7ffff6df0070) at thirdparty/boost-1.66.0/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90 #3 boost::interprocess::interprocess_recursive_mutex::lock (this=0x7ffff6df0070) at thirdparty/boost-1.66.0/include/boost/interprocess/sync/interprocess_recursive_mutex.hpp:163 #4 boost::interprocess::scoped_lock<boost::interprocess::interprocess_recursive_mutex>::lock (this=<synthetic pointer>) at thirdparty/boost-1.66.0/include/boost/interprocess/sync/scoped_lock.hpp:284 #5 boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_get_lock (use_lock=true, this=0x7ffff6df0010) at thirdparty/boost-1.66.0/include/boost/interprocess/segment_manager.hpp:1315
(gdb) f 1 #1 0x00007ffff7bc3e42 in __GI___pthread_mutex_lock (mutex=0x7ffff6df0070) at ../nptl/pthread_mutex_lock.c:115 115 ../nptl/pthread_mutex_lock.c: 没有那个文件或目录. (gdb) p *mutex $1 = {__data = {__lock = 2, __count = 2, __owner = 19759, __nusers = 1, __kind = 129, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\002\000\000\000/M\000\000\001\000\000\000\201", '\000' <repeats 22 times>, __align = 8589934594}
It's a single-threaded program, however the mutex infomation shows the owner is 19759.
I'm using boost-1.66.0.
Here is my test code. The file exceeds the limit, Can I email you?
#include <iostream> #include <boost/interprocess/managed_mapped_file.hpp> #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/containers/string.hpp> namespace bip = ::boost::interprocess; using SegmentManager = bip::managed_mapped_file::segment_manager; using Allocator = bip::allocator<char, SegmentManager>; using String = bip::basic_string<char, std::char_traits<char>, Allocator>; int main() { auto segment = std::make_shared<bip::managed_mapped_file>( bip::open_or_create, "./test_mmap", 1024*1024*10); (*segment).template find<String>("test"); std::cout << "find" << std::endl; return 0; }
I can't reproduce the problem, could you provide a small compilable test case?