Boost C++ Libraries: Ticket #4010: Boost message queue bug

Mon, 15 Mar 2010 06:06:01 GMT

*Note: What I mean is the "boost::interprocess::message_queue" class.

Thu, 15 Apr 2010 10:08:35 GMT

This is even more serious! The problem seems to apply to all named Boost.Interprocess resources (e.g. shared memory and named semaphores).

As a workaround I have rebuilt my code without the pre-processor symbols BOOST_INTERPROCESS_HAS_WINDOWS_KERNEL_BOOTTIME and BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME. I believe this would give me filesystem-persistence but this should be ok since the documentation is stating that all named resources could have either filesystem or kernel persistence.

cc set

Thu, 15 Apr 2010 10:09:44 GMT

cc anders.widen@… added

anonymous — Thu, 06 May 2010 04:27:25 GMT

Thanks for this bug, it saves us a lot of time to trace a bug: when the applications are running for a few hrs, they won't communicate correctly with each other if the child process is created dynamically.

I have a simple fix for this, only works for windows system. Try to use the windows_shared_memory instead of shared_memory_object. It works as changing the system time, not test on leave it there for a few hrs. If anyone interested in the changes: replace detail::managed_open_or_create_impl< windows_shared_memory, false> m_shmem; with detail::managed_open_or_create_impl<shared_memory_object> m_shmem; and change the header include. comment out the message_queue::remove.

Hope this could help some1 on Windows to work around this problem by now.

dxj19831029@… — Thu, 06 May 2010 04:29:39 GMT

Hope this could help some1 on Windows to work around this problem by now.

klaas@… — Tue, 27 Jul 2010 11:42:27 GMT

I also noted this bug. It happened when using a shared_memory_object. We have a windows service that keeps running that we communicate with. After a while we had clients that failed to communicate with it.

I tracked down the bug. It seems that NtQuerySystemInformation is used in get_system_time_of_day_information to create the path to store the files for sharing the memory. I noticed that after windows changed the time/date either by the Windows Time synchronization or by doing it manually, NtQuerySystemInformation returned another boot time then before. Because of this, when another process was started and tried to communicate with the windows service it failed as it was looking for the files in a different directory.

I don't really have a suggestion with a decent fix. A workaround could be disabling the Windows Time service that does automatic synchronization (this workaround is untested).

Ion Gaztañaga — Tue, 27 Jul 2010 12:21:20 GMT

Try latest trunk code. NtQuerySystemInformation has been replaced with a call to WMI (slower, but I think it's much more robust).

status, milestone changed; resolution set

Ion Gaztañaga — Thu, 26 Aug 2010 10:20:26 GMT

status new → closed
resolution → fixed
milestone Boost 1.43.0 → Boost-1.45.0

Fixed for Boost 1.45 in release branch

marek — Wed, 17 Nov 2010 10:16:52 GMT

i have been hit by this bug for longer also and always use workaround

testing beta 1.45 release now

seems now it is working on my vista(32bit) OS. but it still fails on legacy XP (32bit) i don't know about others versions

so i back to use my work-around of this problem and it is working smoothly again

\boost\boost\interprocess\detail\tmp_dir_helpers.hpp

#if defined (BOOST_INTERPROCESS_HAS_WINDOWS_KERNEL_BOOTTIME)
inline void get_bootstamp(std::string &s, bool add = false)
{
   std::string bootstamp;
   winapi::get_last_bootup_time(bootstamp);
+   bootstamp = "";
   if(add){
      s += bootstamp;
   }
   else{
      s = bootstamp;
   }
}
#elif defined(BOOST_INTERPROCESS_HAS_BSD_KERNEL_BOOTTIME)

if any1 else is seeing this it may be worth reopening this bug

thanks

Andrey Semashev — Wed, 17 Nov 2010 20:09:16 GMT

I took a look at the WMI code and noticed that in a few places you pass wide strings to COM methods. Strictly speaking, this is not correct because COM methods accept BSTRs, which are binary incompatible with wide C strings, unless the method implementation treats them as wide C strings. In particular, if it calls SysStringLen on the argument, the result will be undefined.

FWIW, from this thread it seems that using WMI has its drawbacks, let alone the complexity. Perhaps, using performance counters would suffice? Here I found an example of reading a few system counters, of which "\Process(System)\Elapsed Time" might be what you need. The registry key also looks interesting but I didn't find a way to interpret it (looks like it changed its format in Vista). I did not dig deep enough into the code though, so this may be of little help to you.