Opened 6 years ago

Last modified 4 years ago

#12659 new Bugs

Deadlocked with boost::interprocess::managed_mapped_file find

Reported by: soumyadutta13@… 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 John Maddock, 6 years ago

Component: Noneinterprocess
Owner: set to Ion Gaztañaga

comment:2 by Ion Gaztañaga, 6 years ago

I can't reproduce the problem, could you provide a small compilable test case?

in reply to:  2 comment:3 by windjianlipf@…, 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;
}
Note: See TracTickets for help on using tickets.