1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC

[nobody]

Hello.

My name is John Daub, email: hsoi@hsoi.com.

I am using CodeWarrior Pro 9.5 on a dual G5/2GHz PowerMac 
(PPC). I believe the version of boost that I am using is 1.33 R1 as 
version.hpp says 1.33 and since 1.33 R2 was released only 2 
days ago, I figure I must be using R1 (I didn't put boost into our 
CVS repository... someone else did that so I can't say what 
version of boost I have any more than that).  However, I did check 
the 1.33 R2 and it seems to have the same problem. Going back 
to 1.32 however, I do not have the problem. It appears to be 
something introduced in 1.33.

The problem stems from my use of the boost::shared_ptr class, 
and then ultimately how shared_ptr uses sp_counted_base to 
track the useCount.  It seems boost 1.33 has introduced compiler 
and processor specific implementations of sp_counted_base. In 
the CodeWarrior PPC version (boost/detail/
sp_counted_base_cw_ppc.hpp) there are 3 inline functions: 
atomic_increment, atomic_decrement, 
atomic_conditional_increment. These 3 inline functions use inline 
assembly to do their work. That's fine.

However, if you set the CW compiler to build with "don't inline", 
things work out fine. You can run and play and no problems.  If 
however you set the CW compiler to "smart" inlining, then you will 
crash because these atomic functions don't work for some reason.  
FWIW, the other inlining options are set as follows: auto-inline is 
off, deferred inling is off, bottom-up inlining is on.

You should be able to reproduce this yourself. I used my CW Pro 
9.5 install and created a new project based upon the Mac OS C++ 
Stationery (the Mac OS Carbon, Standard Console, C++ Console 
Carbon, stationery).  I added an access path to my boost library 
folder, and I added your own test file from boost-distro/libs/
smart_ptr/shared_ptr_test.cpp to the project. I changed nothing 
else about the project... just stock CodeWarrior stationery.

If you ensure inlining is set to "don't inline", build, and it runs fine. 
If you then go back, change the setting to "smart" inlining, rebuild, 
and then run, you should see the console window comes up, 
some stuff appears in the window but quickly things crash. The 
problem is the useCount doesn't seem to increment, so when it 
later decrements, the count is off and things go wrong.

[nobody]

Logged In: NO 

This is John Daub (hsoi@hsoi.com) again.

I should mention a few other things.

These builds are for CodeWarrior PPC, building old-school CFM apps. I 
don't know if that will make a difference or not. Mach may be different, 
using GCC/Xcode may also be different. I have not tried.

I also have not tried setting the inlining options in other ways. For 
instance, setting it to a specific inline level instead of just "smart". Also, 
I have not fiddled with other options such as turning off bottom-up 
inlining or turning on deferred inlining.

Finally, it may be that this is a CodeWarrior bug. If it is, I'll leave it to 
you to report it to them. Either way it's still a problem that you have to 
deal with and/or work around in your code, so I felt it was worthwhile to 
report to you.

[nobody]

Logged In: NO 

Hello.

This is John Daub (hsoi@hsoi.com) again, with some additional 
information.

When you set the CodeWarrior compiler's inline depth to "smart", the 
compiler will choose a depth between 2 and 4. So I wondered, what if I 
set the depth to 1. To my surprise, things didn't crash, in my app nor in 
using the boost regression test for shared_ptr (as I mentioned earlier). 
However, things were not operating correctly... in the regression test, 
there were 54 errors.

I tried inline depth of 2. In my app, things did not crash (at level 3 it did 
crash). But in the regression test suite, a depth of 2 did crash.

As well, I did fiddle with other inline options such as "auto-inline", 
"deferred inline" and "bottom-up inline", and while they may have 
affected things, the end result of crashing was still the same. :-(

FWIW, a buddy of mine at the office has been using this same boost 
code as me in a different project. He's also using CodeWarrior 9.5, and 
more or less all things are the same for us except that he's targeting 
Mach-O and I'm targeting CFM. In his code, he is not crashing, and he's 
even got his inline depth set via #pragma to 256. Still, he's going to do 
some debugging to see if he's getting lucky... maybe increment is 
working for him and decrement is not, thus he's just leaking and not 
crashing.

As for me, I see three workarounds.

1. revert to boost 1.32... which isn't an option for me right now. (it's not 
within my control to make this choice).

2. set inlining to "don't inline" for all our projects. Not ideal, but better 
than not crashing.

3. since my particular project happens to be an old-school CFM app, no 
preemptive threads (just a couple threads are used, and they're old 
Thread Manager cooperative threads), I could just #define 
BOOST_SP_DISABLE_THREADS and get the old stock version.

[Peter Dimov]

Logged In: YES 
user_id=305912

A tentative fix is now in CVS:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/detail/sp_counted_base_cw_ppc.hpp?rev=1.5