Date: Tue, 5 Oct 2010 11:37:35 +0200 From: Igor R <boost.lists@gmail.com> 2010/10/5 Yana A Kireyonok (aka Iron Bug) <death.iron.bug@gmail.com>:

...

Greetings, ppl. I've got strange problems with the latest stable boost (1.44.0) and MSVS studios 2005 and 2010. ... According to your description, it seems that the issue you encountered is only a symptom of some memory-management issue in your code .....

Well, it could happen if I wasn't a professional programmer (over 15 years of real time systems hardware and software programming). It's not a typical beginners mistake, for sure. I wouldn't bother ppl in here if I hadn't checked all possible variants and wasn't sure it was really something out of order.

Date: Tue, 5 Oct 2010 12:38:02 +0000 From: David Ward <davidjward30@hotmail.com>

...

Greetings, ppl. I've got strange problems with the latest stable boost (1.44.0) and MSVS studios 2005 and 2010.

Hi, You might want to check out this known bug with std::deque in MSVC. It's due to be fixed in VC11: https://connect.microsoft.com/VisualStudio/feedback/details/533131/bug-in-st... Regards, David.

Yes, this is very possible! I performed some more experiments, encountering the bug issue you mentioned and in my case it seems being the pop_front method that ruins the iterators, despite of using interlocking mechanism. Perhaps, it's the matter of timings: that's why it doesn't trigger when I use other locking methods. But I should uproot using deques in my code, anyway. It may show up again on faster or slower machines. Well, I will be aware of danger of using deques in MSVS. Never liked MS, to say the truth... :) But have to deal with it sometimes. Still, remains the question what to do with constructor of boost::thread in MSVS 2010. It fails with access violation, without any specific conditions, in simple plain piece of code.