Boost logo

Boost Users :

Subject: Re: [Boost-users] Problems with boost 1.44.0 and MSVC: deque problem seems solved, but the boost::ctor problem remains
From: Yana A Kireyonok (aka Iron Bug) (death.iron.bug_at_[hidden])
Date: 2010-10-06 02:28:45


> Date: Tue, 5 Oct 2010 11:37:35 +0200
> From: Igor R <boost.lists_at_[hidden]>
> 2010/10/5 Yana A Kireyonok (aka Iron Bug) <death.iron.bug_at_[hidden]>:
>> 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_at_[hidden]>
>
>> 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-std-deque-non-conforming-invalidation-of-iterators-after-pop-front?wa=wsignin1.0
> 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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net