From: Steve Ramsey (steve_at_[hidden])
Date: 2005-08-21 15:28:37
I've had a number of programs crash after recompiling with the 1.33.0
release and eventually tracked the problems down to shared_ptr,
specifically the atomic_decrement function provided in
sp_counted_base_cw_ppc.hpp. So far, I've only noted problems on a
dual processor G5 running OS X 10.4.2, most often when a shared_ptr
created as a temporary object goes out of scope and the destructor
gets called. I was able to eliminate the problem by replacing the
hand-rolled asm atomic routines with equivalent system routines from
CarbonCore/DriverSychronization.h (except for
atomic_conditional_increment, which I don't have an equivalent for).
I'm not a PPC asm guru, or even a threading/mp guru, so I haven't
been able to properly evaluate the boost functions. I do know that I
was getting access exceptions upon execution of the sync instruction
in the affected areas of the code. This was using CodeWarrior 9.5 to
compile, with optimizations disabled, but inlining activated (the
decrement was being inlined). In my (limited) research into the
problem, I haven't been able to find any good examples of hand-rolled
atomic ops that are mp-savvy, though I found plenty of dire warnings
against making the attempt and numerous recommendations to use either
the kernel-level or Carbon-level routines instead, depending on context.
What additional information can I provide and who can I provide it
to? I haven't spent enough time on this to conclude definitively that
the problem is in the boost source, as it might be CodeWarrior's
munging of it that causes the problem. It's unlikely to be an issue
in my code, as I've seen the issue pop up in relation to several
different constructs, all of which appear to be legal C++ to me. I
won't be pursuing this independently, as the workaround I've found
solves my immediate problem and lets me get back to work after
killing a couple of days playing around with it.
Steve