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?