CODEWITHSUNDEEP
c++debuggingshared-memoryboost-interprocess
brneuro
brneuro

Reputation: 326

how to free managed_shared_memory after a program crash: what are effective techniques to use during debugging?

Admittedly I am a novice and self-taught programmer, and am finally venturing into the depths and power of C and C++. Some things that come with this self-learning process are not textbook or overtly googleable knowledge, such as tricks to use in difficult circumstances, and debugging strategies.

I am using boost::interprocess to set up shared memory using the managed_shared_memory and named objects. Unsurprisingly, my program crashes here and there for a number of reasons during my development. So far, I am rather unfamiliar with debugging tools, especially in linux. As a consequence, many times my shared memory does not get removed properly, as the crashing can result in destructors never being called, etc.

So, after such a program crash, when I attempt to run my application again, when my code tires to allocate a new segment of shared memory I see messages like:

terminate called after throwing an instance of 'boost::interprocess::interprocess_exception'
  what():  boost::interprocess_exception::library_error

which I understand is the result of the lingering shared memory of the same name that never got closed, and is now rogue. I have tried using the

open_or_create

flag in my application, in hopes that subsequent instances of my program would reconnect that shared memory, and then I could find/clear the previous objects in the segment, and start over as if it were a fresh run. However, this doesn't happen. My application throws the above error, or hangs, and I can't proceed with subsequent attempts at running my program.

What is an effective way of clearing out shared memory after a crash like this, so that I can run again after editing/rebuilding my application?

Right now, the only thing I can do is to do my best to avoid these crashes. But when crashes do occur, all I know how to do at the moment to run again successfully is to first reboot. Time consuming, and awkward, and certainly short of something optimal a more experienced programmer would do.

Any suggestions would be appreciated! Thanks, B

EDIT: Is there any specific advice how to proceed with ipcs and ipcrm?

On a fresh boot, I can run ipcs, then my app, then ipcs a second time (while my app is still open, and shared memory still accessible), and I see no difference in any shared memory segments.

I am allocating memory with a statement that looks like this

managed_shared_memory segment(open_or_create, "sharedMemtest", 1048588)

Upvotes: 2

Views: 900

Answers (1)

Eric
Eric

Reputation: 1

Add 

 shared_memory_object::remove("sharedMemtest");

before your 

managed_shared_memory segment(open_or_create, "sharedMemtest", 1048588);

Upvotes: -1

Related Questions