boost::interprocess_exception - library_error exception when creating shared_memory_object

[Oleg]

​Problem description and workaround

[anonymous]

Can this please get some attention? This bug means that if the system is up long enough for the event with id 6005 to be rolled out of event logs, this will always fail. It is unreliable implementation of getting last bootup time. Code comes from

boost\interprocess\detail\win32_api.hpp

Obtains the bootup time from the System Event Log, event ID == 6005 (event log started). Adapted from ​http://msdn.microsoft.com/en-us/library/windows/desktop/bb427356.aspx inline bool get_last_bootup_time(std::string &stamp)

[Ion Gaztañaga]

Can you check ticket #11480 (​https://svn.boost.org/trac/boost/ticket/11480) and see if the experimental feature solution can work in your case?

[janwilmans@…]

it's not really a viable workaround in many cases, because you would have to do this befor eevery time you create a shared_memory_object...

[Ion Gaztañaga]

I don't understand your point. The event log is not reliable, so we need an alternative.

You can update the code to the develop or master branch and define BOOST_INTERPROCESS_BOOTSTAMP_IS_SESSION_MANAGER_BASED in your project, and see if that alternative (without using the event log) is more reliable. This breaks binary compatibility but at least for new applications might work.

[janwilmans@…]

igaztanaga: I was not responding to your solution, I was referring to the workaround mentioned on stackoverflow, no being a viable workaround, because the event-log can be cleared at any time, and also for system with a long uptime and/or many event-log messages, the message can be lost because it is pushed out of the cyclical buffer.

[anonymous]

Re comment 3: Sorry, but we can't move to development branch (company using boost 1.60 in production environment). Is this new feature scheduled for 1.63?

Also, the client code using this boost functionality is likely 3rd party, so we wouldn't be able to easily test it.

[Jan Wilmans <janwilmans@…>]

We also cannot move to test-branches, our organization requires that we use official releases.

I'm not aware of the internal requirements for a shared_memory_object, but specifically for boost::interprocess::named_mutex, why is not mapped to the CreateMutex API on win32?

(​https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx)

Our current workaround is to use this API directly.