Re: [boost] [interprocess] SHARING_VIOLATION due to antivirus

Subject: Re: [boost] [interprocess] SHARING_VIOLATION due to antivirus
From: Lars Hagstrom (lars_at_[hidden])
Date: 2009-08-19 03:40:07

I made a quick patch to create_file in win32_api.hpp (the patch is 
rather verbose, to make its workings obvious):

static inline void *create_file(const char *name, unsigned long access, 
unsigned long creation_flags, unsigned long attributes = 0)
{
     int tries = 0;
     for (;;)
     {
         void * const res = CreateFileA(name, access, file_share_read | 
file_share_write | file_share_delete, 0, creation_flags, attributes, 0);
         if (tries > 100)
         {
             //ran out of attempts, return and let the exceptions fly
             return res;
         }
         if (res != invalid_handle_value)
         {
             //all went well, return
             return res;
         }
         else if (GetLastError() != 32)
         {
             //we got some other error than an ERROR_SHARING_VIOLATION,
             //let the caller handle the error.
             return res;
         }

         Sleep(1);
         ++tries;
     }
}

With this added my program works fine. I'm not sure whether this sort of 
stuff is needed in any of the other functions in win32_api.hpp.

Cheers
Lars

Lars Hagstrom wrote:
> Hi,
> 
> I've discovered that there is some unfortunate interaction of 
> boost::interprocess and at least one antivirus product (ESET Nod32). The 
> problem manifests on some installations, and the symptom is that an 
> interprocess_exception with a native error code of 32 
> (ERROR_SHARING_VIOLATION) occurs when a named_semaphore (or other named 
> objects) are opened (well, I've only seen it when opening, but depending 
> on the AV product I guess it may happen when creating as well).
> 
> Googling a bit on this I found http://support.microsoft.com/kb/316609, 
> which suggests that AV products take exclusive locks on files just as a 
> file is being opened, which sometimes upsets calls to CreateFile. What 
> they suggest is doing retries when a sharing violation occurs.
> 
> I'm not really saying that this is a boost.interprocess bug, but at 
> least for me it would be handy if it was a little bit more tolerant 
> towards AV products.
> 
> I've managed (after quite a lot of hard work) to get a test environment 
> where I can reproduce this quite easily, so I'm more than willing to 
> help out with testing.
> 
> Cheers
> Lars
>