[boost] [Boost-bugs] [ boost-Bugs-1256121 ] 1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC

From: SourceForge.net (noreply_at_[hidden])
Date: 2005-08-10 14:29:49

Bugs item #1256121, was opened at 2005-08-10 12:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256121&group_id=7586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: smart_ptr
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Peter Dimov (pdimov)
Summary: 1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC

Initial Comment:
Hello.

My name is John Daub, email: hsoi_at_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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256121&group_id=7586

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Boost-bugs mailing list
Boost-bugs_at_[hidden]
https://lists.sourceforge.net/lists/listinfo/boost-bugs