boost::interprocess, allocators and containers of containers
I'm attempting to create a buffered queue backed by a memory mapped file. The main data structure is a boost::interprocess::list of boost::interprocess::shared_ptr< Buffer<T> >. Buffer<T> is a struct that has two members: an interprocess_upgradable_mutex and a interprocess::deque. When I attempt to push an item into the deque contained by the struct I get a SIGSEGV in rbtree_best_fit::priv_mark_as_free_block() at line 1153 when using boost 1.43. I'm passing the allocator to the constructor of the deque as instructed in the documentation and I'm using all types which should be boost::interprocess safe. I've spent a couple hours on this one item and I'm not making any progress; I was wondering if someone could please lend me a hand. Source excerpt and backtrace: https://gist.github.com/ff7912d4582d68b825c3 Thanks, Matt Stump P.S. Other helpful criticism of my usage or advice on boost::interprocess would be greatly appreciated.
On 13/07/2010 5:28, Matthew Stump wrote:
I'm passing the allocator to the constructor of the deque as instructed in the documentation and I'm using all types which should be boost::interprocess safe. I've spent a couple hours on this one item and I'm not making any progress; I was wondering if someone could please lend me a hand.
It does not seem you have anything wrong. Can you send a reduced and still crashing compilable example? Best, Ion
I actually solved it late last night right before falling asleep. I was refactoring what I considered rough spots, one of which being the initialization of the managed_mapped_file m_file. For expediency (laziness) I had originally set the file size to 1M, I would then construct my empty data structures and grow the file to the appropriate size. Once refactored to set the file size to the correct value during file creation everything began to work. It seems that even though the file is physically larger the allocators do not register the new size, and will segfault if they come up against the original file limit. I had originally thought that maybe I was running out of room in the file, but had discounted that hypothesis. While debugging I was able to get the value of managed_mapped_file.get_free_memory() which returned over 10M at the time. Now after reading the documentation for segment_manager this seems to make perfect sense. I might have to go back to an earlier design which used a different file for each buffer. Thank you for your help. --MS On Jul 13, 2010, at 7:55 AM, Ion Gaztañaga wrote: On 13/07/2010 5:28, Matthew Stump wrote:
I'm passing the allocator to the constructor of the deque as instructed in the documentation and I'm using all types which should be boost::interprocess safe. I've spent a couple hours on this one item and I'm not making any progress; I was wondering if someone could please lend me a hand.
It does not seem you have anything wrong. Can you send a reduced and still crashing compilable example? Best, Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Ion Gaztañaga -
Matthew Stump