Boost C++ Libraries: Ticket #8945: managed_shared_memory::find assertion

attachment set

bersac_1@… — Wed, 31 Jul 2013 09:01:04 GMT

attachment → boost_interprocess_test.zip

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

Ion Gaztañaga — Tue, 15 Oct 2013 20:15:10 GMT

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 — Fri, 03 Apr 2015 11:53:11 GMT

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@… — Fri, 03 Apr 2015 11:53:58 GMT

anonymous — Fri, 03 Apr 2015 12:27:46 GMT

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

datalligator@… — Fri, 03 Apr 2015 14:04:19 GMT

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.

attachment set

imak@… — Sat, 25 Apr 2015 23:31:49 GMT

attachment → trace.txt

stack trace deadlock

attachment set

imak@… — Sat, 25 Apr 2015 23:32:23 GMT

attachment → trace.2.txt

stack trace deadlock

attachment set

imak@… — Sat, 25 Apr 2015 23:32:33 GMT

attachment → trace.3.txt

stack trace deadlock

attachment set

imak@… — Sat, 25 Apr 2015 23:33:36 GMT

attachment → trace.4.txt

stack trace deadlock

imak@… — Sat, 25 Apr 2015 23:38:50 GMT

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 — Fri, 12 Feb 2016 05:32:15 GMT

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