Fix resource leak caused by move ctor/assignment

[elfenpiff]

Required information

All versions

Observed result or behaviour: The classes:

• [x] unix_domain_socket (fixed by https://github.com/eclipse-iceoryx/iceoryx/pull/550)
• [x] shared_memory
• [x] memory_map
• [x] GenericRAII

are not cleaning up the resources while performing move. This could lead to a resource leak when for instance the following pseudo code is executed.

SharedMemory mySharedMemory; // create a shared memory file A
SharedMemory anotherSharedMemory; // create a shared memory file B

mySharedMemory = std::move(anotherSharedMemory); // mySharedMemory takes ownership of B without releasing A

// at this point the shared memory file A is leaked

Classes with correct move resource handling:

• Semaphore
• MessageQueue
• optional
• variant

Handle undefined state:

• [x] optional
• [x] expected

creation pattern:

• [x] shared_memory
• [x] shared_memory_object
• [x] memory_map

Fix incorrect move CTor/assigned in all classes derived from DesignPattern::Creation According to: https://isocpp.org/wiki/faq/assignment-operators every move ctor/assignment operator has to be implemented like

Derived& Derived::operator= (Derived&& d)
{
  // self-assignment is not allowed in move assignment
  Base::operator= (std::move(d));
  // Do the rest of your assignment operator here...
  return *this;
}

• [x] shared_memory
• [x] shared_memory_object
• [x] memory_map
• [x] semaphore
• [x] message_queue
• [x] unix_domain_socket
• [x] Write a detailed documentation how to use the creation pattern correctly - especially the assignment operator part!

Fix sighandler

• [x] Write mini sigaction abstraction and put it into utils to remove the 5 lines of code.
• [x] Use posix::SignalHandler everywhere

Details

• Consider this discussion

[elfenpiff]

@sschnitzer Thank you for finding this!