Latest boost update boost-*-1.44.0-0.6 causes nona to crash. (gdb) run -z PACKBITS -r ldr -m TIFF_m -o IMG_2803-IMG_2818-eq -i 0 IMG_2803-IMG_2818-eq.pto Starting program: /usr/bin/nona -z PACKBITS -r ldr -m TIFF_m -o IMG_2803-IMG_2818-eq -i 0 IMG_2803-IMG_2818-eq.pto [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. operator= (this=0x660c60) at /usr/src/debug/boost-1.44.0.cmake/boost/smart_ptr/shared_ptr.hpp:305 305 this_type(r).swap(*this); (gdb) bt #0 operator= (this=0x660c60) at /usr/src/debug/boost-1.44.0.cmake/boost/smart_ptr/shared_ptr.hpp:305 #1 boost::thread::start_thread (this=0x660c60) at /usr/src/debug/boost-1.44.0.cmake/libs/thread/src/pthread/thread.cpp:185 #2 0x0000003a15cb3521 in boost::thread* boost::thread_group::create_thread<boost::function0<void> >(boost::function0<void>) () from /usr/lib64/libhuginbase.so.0.0 boost*-1.44.0-0.4 works fine.
hmm... you have overwritten boost-1.44.0.cmake.tar.bz2 in the fedora git, that makes it more difficult to debug. Why didn't you upload the git version with a different name?
(In reply to comment #1) > hmm... you have overwritten boost-1.44.0.cmake.tar.bz2 in the fedora git, that > makes it more difficult to debug. > > Why didn't you upload the git version with a different name? You're right. The tar-ball is now reflecting exactly the final 1.44.0 release of Boost, to which have been added "only" CMake-enabled building support files. However, the former tar-balls, with the same name (boost-1.44.0.cmake.tar.bz2), were "alpha" or beta versions. Boost themselves are not very clear with their transitional versions. For instance, patches have been made to the branches/release part of the Subversion repository (http://svn.boost.org/svn/boost/branches/release), but not reported onto the tags/release/Boost_1_44_0 part (http://svn.boost.org/svn/boost/tags/release/Boost_1_44_0). So, you are right: I should certainly have chosen names such as boost-1.44.0-git{4,5,6}.cmake.tar.bz2, it would have been clearer. If you need older tar-balls, I still have them. But, as far as I know, they did not reflect exactly the same content as was present in upstream Boost. For instance, the tar-ball corresponding to boost-1.44.0-4 contains some header files not present in pristine Boost-1.44 (such as, out of my memory, boost/random/detail/{enable,disable}_wanings.hpp). As a summary: * The former tar-balls I used for packaging Boost-1.44 in Fedora were not reflecting exactly upstream Boost content. That corresponds to packages boost-1.44.0-1 to boost-1.44.0-5. * The tar-ball used for the packaging of Boost-1.44, in the boost-1.44.0-6 package, does now reflect pristine Boost content for the final release of Boost-1.44 (http://svn.boost.org/svn/boost/tags/release/Boost_1_44_0). * I suggest to re-build Fedora packages based on that boost-1.44.0-6 package, open bug reports for the packages failing to compile, and fix the corresponding bugs (with support from upstream Boost teams). It will be much cleaner and easier to maintain, as we shall follow upstream Boost content (except for the building part, of course). [Most of the Fedora packages based on Boost have compiled gracefully with boost-1.44.0-5, but that is not so good news, as the corresponding content was not that much consistent with upstream Boost...]
I downloaded the old src.rpms and looked at the source diff. The differences are so big, that it would justify different major .so versions... So please let all packages, which use boost to be recompiled!!
(In reply to comment #3) > So please let all packages, which use boost to be recompiled!! I do agree! If you have any idea on how to fix the segmentation fault (which apparently also occurs for qbittorrent, as reported in https://admin.fedoraproject.org/updates/boost-1.44.0-0.6.fc14), do not hesitate.
(In reply to comment #0) > Latest boost update boost-*-1.44.0-0.6 causes nona to crash. Could you tell me where to find nona (I cannot find it on neither Fedora 13 nor Rawhide, and a search on Google does not help that much)?
I am not sure it helps, but many changes were made to Boost-1.44 at the beginning of July, 2010. For instance: http://gitorious.org/~denisarnaud/boost/denisarnauds-zeuners-boost-cmake/commit/88d16695701d88d10a836c12974f3ec04a4698eb There have been subsequent smaller changes too.
I reported the qbittorent problem mentioned in Comment 4. I have a few questions I hope you can answer. 1. Do you need any more information qbittorent seg fault? 2. Should I report a bug against qbittorrent requesting that it be rebuilt against the new boost? 3. Does this mean there will be another mass rebuild against the new upstream version? Thanks, Gene
(In reply to comment #5) > (In reply to comment #0) > > Latest boost update boost-*-1.44.0-0.6 causes nona to crash. > > Could you tell me where to find nona (I cannot find it on neither Fedora 13 nor > Rawhide, and a search on Google does not help that much)? hugin-base # yum install /usr/bin/nona Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit Setting up Install Process Package hugin-base-2010.0.0-4.fc14.x86_64 already installed and latest version Nothing to do
(In reply to comment #7) > 1. Do you need any more information qbittorent seg fault? Not for now. Apparently, the stack of your core dump looks similar to the one generated by nona. But do not hesitate to investigate on your side (with qbittorrent). > 2. Should I report a bug against qbittorrent requesting that it be rebuilt > against the new boost? In case you can extract an easier-to-reproduce test case, it would be a good idea to report a bug on the Boost mailing list and/or on the qbittorrent development mailing list. > 3. Does this mean there will be another mass rebuild against the new upstream > version? Nevertheless, there will be a massive rebuild for Fedora 14 beta. So, we have first to fix that bug related to (Boost) smart pointer and thread. Thanks for your support!
Bug #624641 has been reopened, as it was fixed with boost-1.44.0-0.6.
(In reply to comment #0) > Starting program: /usr/bin/nona -z PACKBITS -r ldr -m TIFF_m -o > IMG_2803-IMG_2818-eq -i 0 IMG_2803-IMG_2818-eq.pto Would it be possible for you, Harald, to publish a .pto file somewhere (and give us the URL), or attach such a file if not too big, so that we can run nano on our local environment?
Created attachment 440145 [details] .pto file for test case of hugin/nona That .pto file relies on two images, named pict1888.jpg and pict1889.jpg, and located in the /home/fedora/tmp directory. You can of course edit that .pto (text) file to adapt it to your example. That .pto has been obtained thanks to the panostart utility (needing the panotools and autopano-sift-c packages, that latter being absent from F14 and Rawhide). The panostart utility generates a Makefile. Then, a simple `make pto' will generate the .pto file.
With a Rawhide distribution, on which Boost-1.44.0-0.6 is still available by default, hugin is built cleanly: Wrote: /<pack>/SRPMS/hugin-2010.0.0-4.fc15.src.rpm Wrote: /<pack>/RPMS/i686/hugin-2010.0.0-4.fc15.i686.rpm Wrote: /<pack>/RPMS/i686/hugin-base-2010.0.0-4.fc15.i686.rpm Wrote: /<pack>/RPMS/i686/hugin-debuginfo-2010.0.0-4.fc15.i686.rpm Once installed, the hugin command cleanly produces the expected result: $ rpm -qi hugin Name: hugin Relocations: (not relocatable) Version: 2010.0.0 Vendor: Fedora Release: 4.fc15 Build Date: Sat 21 Aug 2010 03:40:10 PM CEST $ nona -z PACKBITS -r ldr -m TIFF -o pict1888-pict1889 -i 0 pict1888-pict1889.pto It produces the following image: 'pict1887-pict1888.tif'. Note that a warning is issued, though: "OJPEGSetupEncode: OJPEG encoding not supported; use new-style JPEG compression instead." The nona binary depends on the Boost::Thread library, as expected: $ ldd -r /usr/bin/nona [...] libhuginbase.so.0.0 => /usr/lib/libhuginbase.so.0.0 (0x066f4000) libboost_thread-mt.so.1.44.0 => /usr/lib/libboost_thread-mt.so.1.44.0 libpano13.so.1 => /usr/lib/libpano13.so.1 (0x05a39000) libhuginvigraimpex.so.0.0 => /usr/lib/libhuginvigraimpex.so.0.0 [...] And: $ rpm -qi boost-thread Name: boost-thread Relocations: (not relocatable) Version: 1.44.0 Vendor: Fedora Project Release: 0.6.fc15 Build Date: Tue 17 Aug 2010 12:50:03 AM CEST ================================ In conclusion, on Rawhide, Hugin-2010.0.0-4 works perfectly with Boost-1.44.0-0.6.
On Rawhide, I forgot to mention that, in order to build Hugin, I used the F14 specification file. With the Rawhide version of the specification file, an error (typo?) has been introduced, having the Koji build to fail: http://koji.fedoraproject.org/koji/taskinfo?taskID=2416237 Indeed, the "BuildRequires: xorg-x11-devel" is no longer restricted to RedHat distributions. However, that package is not available on Fedora, causing mock to fail. The solution is just to come back to the F14 version for that part of the specification file: %if 0%{?rhl} >= 4 BuildRequires: xorg-x11-devel %endif I cannot fix the specification file, as I have no write access to the Fedora package (Git) repository: https://admin.fedoraproject.org/pkgdb/acls/name/hugin
boost-1.44.0-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/boost-1.44.0-1.fc14
Hugin successfully built on Fedora Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=191494
And on Fedora 14: http://koji.fedoraproject.org/koji/taskinfo?taskID=2418063
boost-1.44.0-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update boost'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/boost-1.44.0-1.fc14
hugin-2010.0.0-5.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/hugin-2010.0.0-5.fc14
The new version, boost-1.44.0-1.fc14, still causes qBittorrent to seg fault. I filed an abrt bug, https://bugzilla.redhat.com/show_bug.cgi?id=626639, against qBittorrent along with the backtrace from the terminal window. I can switch that but to boost if you think that's appropriate. Gene
(In reply to comment #20) > The new version, boost-1.44.0-1.fc14, still causes qBittorrent to seg fault. I > filed an abrt bug, https://bugzilla.redhat.com/show_bug.cgi?id=626639, against > qBittorrent along with the backtrace from the terminal window. I can switch > that but to boost if you think that's appropriate. > > Gene It isn't qbittorrent at fault, rb_libtorrent needs to be recompiled against the new boost version.
Thanks Leigh, I see you switched the component in my bug report. Gene
(In reply to comment #20) > The new version, boost-1.44.0-1.fc14, still causes qBittorrent to seg fault. It seems that the issue comes from a misalignment between the compiled version of qbittorrent (or, more specifically, of rb_libtorrent), built with boost-1.44.0-0.5, which is still the package by default on F14, and the runtime environment with boost-1.44.0-1 (the one you test with). Indeed, a great amount of code has changed between both versions (i.e., between boost-1.44.0-0.5 and later versions), and in particular code related to Boost::Thread. So, that misalignment issue can be easily understood. The only solution would be to do a chain build (which will be the case for the next massive rebuild, e.g., for F14 beta) of boost and of the packages depending on boost; or to rebuild qbittorrent (and its components depending on boost) against boost-1.44.0-1. Could you do that (you can a local build; Koji will not be able to do it, as boost-1.44.0-1 is not the default version for F14)? If not, we'll have to wait that boost-1.44.0-1 reaches the stable repository (if nobody opposes again...). Note that on Rawhide, where boost-1.44.0-1 has been the default package for a week, qbittorrent seems to work correctly. So, I'm confident that, in case boost-1.44.0-1 reaches the stable repository, and when qbittorrent will be rebuilt against that version, everything will work again like a charm.
Rebuilding rb_libtorrent against the new boost fixed the qBittorrent segmentation faults. It doesn't appear to be necessary to rebuild qBittorrent. Thanks for the info, Gene
(In reply to comment #23) > The only solution would be to do a chain build (which will be the case for the > next massive rebuild, e.g., for F14 beta) of boost and of the packages > depending on boost; or to rebuild qbittorrent (and its components depending on > boost) against boost-1.44.0-1. Is it feasible to add a buildroot override for boost for F14 now?
per comment #25 , i've tagged this for buildroot override, see also https://fedorahosted.org/rel-eng/ticket/4003
boost-1.44.0-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
hugin-2010.0.0-6.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/hugin-2010.0.0-6.fc14
hugin-2010.0.0-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.