Opened 5 years ago

Last modified 3 years ago

#8945 new Support Requests

managed_shared_memory::find assertion

Reported by: bersac_1@… Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.54.0 Severity: Problem
Keywords: Cc:

Description

Hi,

I am using ubuntu 13.04 and the compilator is : g++ (Ubuntu/Linaro? 4.6.3-1ubuntu5) 4.6.3 I have an application which successfully opened a shared memory (I checked with another client). The problem is, when a client of this shared memory tried to connect, the managed_shared_memory::find is blocking or throw the following error message (I don't know what cause my program to have one of this error rather than the other) :

mosaique: /usr/local/include/boost/interprocess/segment_manager.hpp:871: void* boost::interprocess::segment_manager::priv_generic_find(const CharT*, IndexType? >&, boost::interprocess::ipcdetail::in_place_interface&, boost::interprocess::segment_manager::size_type&, boost::interprocess::ipcdetail::true_, bool) [with CharT = char, CharType? = char, MemoryAlgorithm? = boost::interprocess::rbtree_best_fit, IndexType? = boost::interprocess::iset_index, boost::interprocess::segment_manager::size_type = long unsigned int, boost::interprocess::ipcdetail::true_ = boost::interprocess::ipcdetail::bool_]: Assertion `(ctrl_data->m_value_bytes % table.size) == 0' failed. Aborted (core dumped)

The size of my shared memory is : 9 953 280 Please help me fix this bug.

The sources : The server is managed in the main_shm_server.cpp file The buggy client is main_mosaique.cpp It use the class SHMClient which is where the problem occur. The strange thing is when I use the same class with the same constructor parameter in another program, it is working.

Attachments (5)

boost_interprocess_test.zip (28.0 KB) - added by bersac_1@… 5 years ago.
The sources of the bug. Focus on the two main and SHMClient
trace.txt (2.9 KB) - added by imak@… 4 years ago.
stack trace deadlock
trace.2.txt (2.9 KB) - added by imak@… 4 years ago.
stack trace deadlock
trace.3.txt (2.9 KB) - added by imak@… 4 years ago.
stack trace deadlock
trace.4.txt (2.9 KB) - added by imak@… 4 years ago.
stack trace deadlock

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by bersac_1@…

Attachment: boost_interprocess_test.zip added

The sources of the bug. Focus on the two main and SHMClient

comment:1 Changed 5 years ago by Ion Gaztañaga

Sorry for the long delay. I can't see anything in the code that could justify the assertion, but I can't reproduce it due to system dependencies. Could you simplify the code to ease the bug detection? Have you already solved the issue?

comment:2 Changed 4 years ago by anonymous

I have uncovered a similar problem: two programs using the same code behave differently. I need to bisect my recent changes but all was working perfectly for months with the same unit tests. What does this assertion mean?

comment:2 Changed 4 years ago by datalligator@…

I have uncovered a similar problem: two programs using the same code behave differently. I need to bisect my recent changes but all was working perfectly for months with the same unit tests. What does this assertion mean?

comment:3 Changed 4 years ago by anonymous

Actually I haven't used this function until recently. Do get hangs or assertion failures tho'. I'll investigate further.

comment:4 Changed 4 years ago by datalligator@…

Well there's something dodgy going on -- I've worked around it in my code -- actually resulting in an improvement to performance: I get all the named objects and use find_or_construct instead when I map the shared_memory and cache the pointers... (memory mapped file BTW). I'll try and produce a small program that reproduces the "find" problem. It's a bit suspect tho' so I might implement this function lower down in my implementation template class -- I can't believe it doesn't work. I'll compare the code for find_or_construct also.

Changed 4 years ago by imak@…

Attachment: trace.txt added

stack trace deadlock

Changed 4 years ago by imak@…

Attachment: trace.2.txt added

stack trace deadlock

Changed 4 years ago by imak@…

Attachment: trace.3.txt added

stack trace deadlock

Changed 4 years ago by imak@…

Attachment: trace.4.txt added

stack trace deadlock

comment:5 Changed 4 years ago by imak@…

I had a similar problem on Windows. The first thing my program does is to open an existing segment and call find, it is quite simple. In one of many runs, it hit the exact same assertion. Then in every subsequent run, it locked on find. I replaced find with find_or_construct, and it kept locking - same behaviour. Unfortunately, this is system dependent and I can no longer reproduce it. I kept a stack trace though. This is where it locked, with find_or_construct. [my apologies the multiple attachments - my browser kept crashing too...]

comment:6 Changed 3 years ago by anonymous

I can reproduce this issue consistently on CentOS 6.3 and 6.4 with Boost 1.59. Here's a program that exhibits such behavior (notice the type mismatch between construct and find):

#include <boost/interprocess/managed_shared_memory.hpp>

int main() {
    using namespace boost::interprocess;
    auto segment = managed_shared_memory(open_or_create, "my_segment", 4096);
    segment.construct<char>("key")();
    segment.find<int>("key");
}

On the first run, it crashes with:

/redacted/boost/interprocess/segment_manager.hpp:861:void* boost::interprocess::segment_manager<CharType?, MemoryAlgorithm?, IndexType?>::priv_generic_find(const CharT*, IndexType?<boost::interprocess::ipcdetail::index_config<CharT, MemoryAlgorithm> >&, boost::interprocess::ipcdetail::in_place_interface&, boost::interprocess::segment_manager<CharType?, MemoryAlgorithm?, IndexType?>::size_type&, boost::interprocess::ipcdetail::true_, bool) [with CharT = char; CharType? = char; MemoryAlgorithm? = boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>; IndexType? = boost::interprocess::iset_index; boost::interprocess::segment_manager<CharType?, MemoryAlgorithm?, IndexType?>::size_type = long unsigned int; boost::interprocess::ipcdetail::true_ = boost::interprocess::ipcdetail::bool_<true>]: Assertion `(ctrl_data->m_value_bytes % table.size) == 0' failed. Aborted (core dumped)

On the second run, it deadlocks with the following strace output:

open("/dev/shm/my_segment", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = 3
fcntl(3, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
fstat(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f1ae837e000
close(3)                                = 0
futex(0x7f1ae837e070, FUTEX_WAIT, 2, NULL
Note: See TracTickets for help on using tickets.