Yes, of course it is due to bad AV. But for me it would still be handy if boost.interprocess was a little bit more tolerant towards that. If my software crashes it will be perceived as buggy, however much I blame AV... Did you have a look at the MS article? You'll notice that they describe this as a general problem, not only with a specific AV product. /Lars OvermindDL1 wrote:

On Tue, Aug 18, 2009 at 1:09 PM, Lars Hagstrom<lars@update.uu.se> 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.

To me, that sounds like a bug in the AV product, since with the code you are only doing what you are supposed to be doing. If the AV itself is acting like a virus and causes bugs like that, it is their fault. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Quoting Lars Hagstrom <lars@update.uu.se>:

...

Yes, of course it is due to bad AV. But for me it would still be handy if boost.interprocess was a little bit more tolerant towards that. If my software crashes it will be perceived as buggy, however much I blame AV...

One thing you can do is to, at startup, detect if nod32.dll is loaded in your process, and throw up a warning dialog to tell the user that the AV software is buggy.

This seems inappropriate since, if anything, the operating system kernel which forces user space programmers into busy waiting for obtaining locks could be considered buggy by design in that regard. However, this bug could even be warned about at compile time, so we could solve this in boost itself. It is probably inappropriate to do so by default, but for administrators of heterogenous systems it might become handy to have a preprocessor flag which can warn if someone is about to deploy software which uses features the operating system was not designed for, so it can be considered to move the application to a more appropriate platform. Best regards, Isidor

On Wed, Aug 19, 2009 at 6:56 AM, OvermindDL1<overminddl1@gmail.com> wrote:

On Tue, Aug 18, 2009 at 1:09 PM, Lars Hagstrom<lars@update.uu.se> wrote:

...

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.

To me, that sounds like a bug in the AV product, since with the code you are only doing what you are supposed to be doing.  If the AV itself is acting like a virus and causes bugs like that, it is their fault.

Microsoft is quite clear in the article: "When you open a file, you must always handle a sharing violation in a graceful manner so that you do not affect the user of the system or cause the system to crash." /$

Lars Hagstrom escribió:

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

Thanks, I'll fix it in trunk ASAP. Microsoft example uses 250ms timeout, so I don't know if just yielding would overkill. I'll investigate it. Best, Ion

Lars Hagstrom escribió:

Excellent! As always, thanks for the excellent library and the fast responses!

Any chances in getting the fix into 1.40? (Caveat: I haven't followed the mailing list for a while, so I have no idea of the state of the release, a simple yes or no is sufficient...)

Too late...

/Lars

Best, Ion

Yes, I quite expected Ion to move the constant to where all the other constants are, at the top of that file. I didn't really mean for the patch to go in as is (and I'm pretty sure Ion wouldn't anyway, my patch isn't really in the same coding style...;-) But you are right! Lars Stewart, Robert wrote:

Lars Hagstrom wrote:

...

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; } }

I think this would be more readable and do the same:

static inline void * create_file(const char * name, unsigned long access, unsigned long creation_flags, unsigned long attributes = 0) { for (int attempt(0); attempt < 100; ++attempt) { void * const handle( CreateFileA(name, access, file_share_read | file_share_write | file_share_delete, 0, creation_flags, attributes, 0)); bool const invalid(invalid_handle_value == handle); if (!invalid) { return handle; } bool const sharing_violation(32 == GetLastError()); if (!sharing_violation) { return handle; } Sleep(1); } return invalid_handle_value; }

This makes the magic number more obvious, too (assuming it were to remain a magic number).

_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost