Re: [Boost-users] Compatibility between shared_ptr and Rational RoseRT

From: Ross Manges (ross.manges_at_[hidden])
Date: 2005-04-27 16:37:47

> and as you can see, another thread may enter the critical region and
write
> retElem in parallel with the return statement, which needs to make a
copy
> of
> retElem and place it in the return value.
Ahh ha!  Thanks for the insight.  That has helped me sqash a few bugs. 
Now I do have one last remaining situation, and I have updated my example
code to use shared_from_this() in a very precarious way.  Is there some
way to make this example work without changing how shared_from_this() is
being used?

Also, I didn't mean to hijack this thread from the RoseRT topic. It just
so happens that we're going to be running this code through Purify in the
near future, so I'm curious if the original poster of this thread has
resolved his FIM errors?

here's my current backtrace:
(gdb) bt
#0  0x0804ae63 in atomic_increment (pw=0x1d) at
sp_counted_base_gcc_x86.hpp:59
#1  0x0804ad4f in boost::detail::sp_counted_base::add_ref_copy (this=0x19)
at sp_counted_base_gcc_x86.hpp:133
#2  0x0804ae0d in shared_count (this=0xb15ef014, r=@0x80966b4) at
shared_count.hpp:170
#3  0x0804b8a0 in shared_ptr (this=0xb15ef010, _ctor_arg=@0x80966b0) at
../Element.cpp:20
#4  0x0804c247 in _Construct<ElementPtr, boost::shared_ptr<Element> >
(__p=0xb15ef010, __value=@0x80966b0) at stl_construct.h:78
<...snip...>