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...>