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

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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs
participants (1)
-
SourceForge.net