managed_shared_memory::find assertion

[bersac_1@…]

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.

[bersac_1@…]

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

[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?

[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?

[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?

[anonymous]

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

[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.

[imak@…]

stack trace deadlock

[imak@…]

stack trace deadlock

[imak@…]

stack trace deadlock

[imak@…]

stack trace deadlock

[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...]

[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