On Sun, 21 Aug 2005, at 16:56, Howard Hinnant wrote:
On Aug 21, 2005, at 4:28 PM, Steve Ramsey wrote:
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.
Try these:
<snip> That seems to have done the trick. Presumably the return value was never making it out of the decrement function, eventually causing double deletes when circumstances were right. Thanks for the quick response; I'll send along another message if this turns out not to be a complete solution, though I don't foresee problems. Steve
Steve Ramsey wrote:
On Sun, 21 Aug 2005, at 16:56, Howard Hinnant wrote:
On Aug 21, 2005, at 4:28 PM, Steve Ramsey wrote:
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.
Try these:
<snip>
That seems to have done the trick. [...]
This fix is already in the main CVS and the RC_1_33_0 branch: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/detail/sp... Since this is a serious issue, can we make a release candidate of 1.33.1 available immediately? We missed several bugs in 1.33.0 because the RC wasn't out earlier. I think that we rely too much on our internal test resources; a beta release or an RC (people seem to test "RC"s more than "beta"s even though the content may be exactly the same) should go out as soon as the CVS is "frozen" to help us find problems in the field.
Peter Dimov writes:
Since this is a serious issue, can we make a release candidate of 1.33.1 available immediately? We missed several bugs in 1.33.0 because the RC wasn't out earlier. I think that we rely too much on our internal test resources; a beta release or an RC (people seem to test "RC"s more than "beta"s even though the content may be exactly the same) should go out as soon as the CVS is "frozen" to help us find problems in the field.
I totally agree. But then technically _there was_ an almost two-week period during which the RC tarballs were readily available for download and tryout and yet obviously most of our users waited until the release was officially out to start looking at it. In that light, I'm afraid that just prolonging the RC period by itself is not going to be as effective as one might hope for. We need more publicity for the RC period, may be as much as for the actual release. -- Aleksey Gurtovoy MetaCommunications Engineering
On 24/08/05, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote: Peter Dimov writes: <snip comments about more testing and longer RC period>
At least two of us are seeing a bug in read_write_mutex too. More testing via a longer period and / or more testers. More testers is obviously but outside the control of boost without volunteers. So, I'm trying to put my money where my mouth is and contribute to the testing but it fails or rather hangs... perhaps on a test... Any ideas? Console below. matt. matthurd@acm.org __________________ matt@aud001:/zomojo/regression_boost> python regression.py --runner=zomojo --toolsets=gcc # Cleaning up "/zomojo/regression_boost/boost" directory ... # Cleaning up "/zomojo/regression_boost/boost/bin" directory ... # Cleaning up "/zomojo/regression_boost/results" directory ... # Getting sources (2005-08-23T08:17:41Z)... # Downloading "http://www.meta-comm.com/engineering/boost/snapshot/boost-CVS-HEAD.tar.bz2" to "/zomojo/regression_boost"... # Looking for old unpacked archives... # Unpacking boost tarball ("/zomojo/regression_boost/boost-CVS-HEAD.tar.bz2")... # Unpacked into directory "/zomojo/regression_boost/boost-CVS-HEAD-05-08-23-0802" # Renaming "/zomojo/regression_boost/boost-CVS-HEAD-05-08-23-0802" into "/zomojo/regression_boost/boost" # Preinstalled "/zomojo/regression_boost/bjam" is not found; building one... # Found "bjam" source directory "/zomojo/regression_boost/boost/tools/build/jam_src" # Building "bjam" (./build.sh gcc)... ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c execunix.c expand.c fileunix.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 43 targets... ...updating 2 targets... [MKDIR] bin.linux [COMPILE] bin.linux/bjam ...updated 2 targets... # Searching for "bjam" in "/zomojo/regression_boost/boost/tools/build/jam_src"... # bjam succesfully built in "/zomojo/regression_boost/boost/tools/build/jam_src/bin.linux/bjam" location # Preinstalled "/zomojo/regression_boost/process_jam_log" is not found; building one... # Found "process_jam_log" source directory "/zomojo/regression_boost/boost/tools/regression/build" # Building "process_jam_log" ("/zomojo/regression_boost/boost/tools/build/jam_src/bin.linux/bjam" "-sBOOST_BUILD_PATH=/zomojo/regression_boost" "-sBOOST_ROOT=/zomojo/regression_boost/boost" "-sTOOLS=gcc")... ...patience... ...found 765 targets... ...updating 28 targets... MkDir1 ../../../bin MkDir1 ../../../bin/boost MkDir1 ../../../bin/boost/libs MkDir1 ../../../bin/boost/libs/filesystem MkDir1 ../../../bin/boost/libs/filesystem/build MkDir1 ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a MkDir1 ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc MkDir1 ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release gcc-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/exception.o gcc-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/operations_posix_windows.o gcc-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/path_posix_windows.o gcc-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/convenience.o gcc-Archive-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/libboost_filesystem-gcc-1_33.a /usr/bin/ar: creating ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/libboost_filesystem-gcc-1_33.a system-Ranlib ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/libboost_filesystem-gcc-1_33.a MkDir1 ../../../bin/boost/tools MkDir1 ../../../bin/boost/tools/regression MkDir1 ../../../bin/boost/tools/regression/build MkDir1 ../../../bin/boost/tools/regression/build/process_jam_log MkDir1 ../../../bin/boost/tools/regression/build/process_jam_log/gcc MkDir1 ../../../bin/boost/tools/regression/build/process_jam_log/gcc/release gcc-C++-action ../../../bin/boost/tools/regression/build/process_jam_log/gcc/release/process_jam_log.o gcc-C++-action ../../../bin/boost/tools/regression/build/process_jam_log/gcc/release/tiny_xml.o gcc-Link-action ../../../bin/boost/tools/regression/build/process_jam_log/gcc/release/process_jam_log Chmod1 ../../../bin/boost/tools/regression/build/process_jam_log/gcc/release/process_jam_log MkDir1 ../../../bin/boost/tools/regression/build/compiler_status MkDir1 ../../../bin/boost/tools/regression/build/compiler_status/gcc MkDir1 ../../../bin/boost/tools/regression/build/compiler_status/gcc/release gcc-C++-action ../../../bin/boost/tools/regression/build/compiler_status/gcc/release/compiler_status.o gcc-C++-action ../../../bin/boost/tools/regression/build/compiler_status/gcc/release/tiny_xml.o gcc-Link-action ../../../bin/boost/tools/regression/build/compiler_status/gcc/release/compiler_status Chmod1 ../../../bin/boost/tools/regression/build/compiler_status/gcc/release/compiler_status ...updated 28 targets... # Searching for "process_jam_log" in "/zomojo/regression_boost/boost/bin/boost/tools/regression/build/process_jam_log"... # process_jam_log succesfully built in "/zomojo/regression_boost/boost/bin/boost/tools/regression/build/process_jam_log/gcc/release/process_jam_log" location # Making "/zomojo/regression_boost/results" directory... # Starting tests ("/zomojo/regression_boost/boost/tools/build/jam_src/bin.linux/bjam" "-sBOOST_BUILD_PATH=/zomojo/regression_boost" "-sBOOST_ROOT=/zomojo/regression_boost/boost" "-sTOOLS=gcc" -d2 --dump-tests "-sALL_LOCATE_TARGET=/zomojo/regression_boost/results"
"/zomojo/regression_boost/results/bjam.log" 2>&1)...
On 24/08/05, Matt Hurd <matt.hurd@gmail.com> wrote:
So, I'm trying to put my money where my mouth is and contribute to the testing but it fails or rather hangs... perhaps on a test... Any ideas? Console below.
Further to this the last few lines of the bjam.log are below. gcc seems to get in a pickle with this and I end up with a cc1plus process running for 981 minutes and counting ;-) --matt. _________________________ mkdir "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug" gcc-C++-action /zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o set -e "g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test" -I "/zomojo/regression_boost/boost" -o "/zomojo/regr ession_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o" "/zomojo/regression_boost/boost/libs/numeric/conversion/test/converter_test.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o"
Matt Hurd wrote:
On 24/08/05, Matt Hurd <matt.hurd@gmail.com> wrote:
So, I'm trying to put my money where my mouth is and contribute to the testing but it fails or rather hangs... perhaps on a test... Any ideas? Console below.
Further to this the last few lines of the bjam.log are below. gcc seems to get in a pickle with this and I end up with a cc1plus process running for 981 minutes and counting ;-)
GCC 3.4, right? There are a couple of tests that cause GCC 3.4 to hang indefinitely. jon
On 24/08/05, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
Matt Hurd wrote: Further to this the last few lines of the bjam.log are below. gcc seems to get in a pickle with this and I end up with a cc1plus process running for 981 minutes and counting ;-)
GCC 3.4, right? There are a couple of tests that cause GCC 3.4 to hang indefinitely.
Close enough 3.3.5 from memory. Time to upgrade from the default distribution installation I guess. Thanks Jon, matt.
Matt Hurd wrote:
On 24/08/05, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
Matt Hurd wrote: Further to this the last few lines of the bjam.log are below. gcc seems to get in a pickle with this and I end up with a cc1plus process running for 981 minutes and counting ;-)
GCC 3.4, right? There are a couple of tests that cause GCC 3.4 to hang indefinitely.
Close enough 3.3.5 from memory. Time to upgrade from the default distribution installation I guess.
I don't (often) test with 3.3 but I think I've seen that doing the same on those problem tests. I haven't figured out what goes wrong, but it's OK with GCC 4.x so upgrading would work. I run the tests with a limit of 5 mins so any compile or test that takes longer than that gets killed - without a limit testing GCC 3.4 never completed. jon -- "It is always the best policy to tell the truth, unless, of course, you are an exceptionally good liar." - Jerome K. Jerome
Aleksey Gurtovoy wrote:
I totally agree. But then technically _there was_ an almost two-week period during which the RC tarballs were readily available for download and tryout and yet obviously most of our users waited until the release was officially out to start looking at it. In that light, I'm afraid that just prolonging the RC period by itself is not going to be as effective as one might hope for. We need more publicity for the RC period, may be as much as for the actual release.
Two weeks isn't long for testing a new boost release in a commercial project. It took us about a week just to get serialization-1.33.0 compiling in our project (using Borland C++Builder) which was already working with boost-1.32.0 Using the rc/beta in production code is a good test, but we do need time to test it. We also have other priorities at work such as meeting deadlines which can span a two week period and so we could miss the RC period altogether before we get a chance to test things. Weekly zip files from when the branch is frozen may help with this (we aren't in a habbit of trying to get out a CVS working copy for production code) but I think at least a month of the freeze period with weekly tar/zip files of the distro main enable more end-users to test before the actual release. Cheers Russell
participants (6)
-
Aleksey Gurtovoy -
Jonathan Wakely -
Matt Hurd -
Peter Dimov -
Russell Hind -
Steve Ramsey