Boost logo

Boost Users :

Subject: Re: [Boost-users] boost::interprocess, allocators and containers of containers
From: Matthew Stump (mstump_at_[hidden])
Date: 2010-07-13 11:54:33


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_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net