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