Bug 624937 - boost*-1.44.0-0.6 crashes nona
boost*-1.44.0-0.6 crashes nona
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Benjamin Kosnik
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 624641
  Show dependency treegraph
 
Reported: 2010-08-18 03:23 EDT by Harald Hoyer
Modified: 2013-08-09 01:50 EDT (History)
8 users (show)

See Also:
Fixed In Version: hugin-2010.0.0-6.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-25 23:26:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
.pto file for test case of hugin/nona (2.73 KB, application/x-ptoptimizer-script)
2010-08-21 13:03 EDT, Denis Arnaud
no flags Details

  None (edit)
Description Harald Hoyer 2010-08-18 03:23:36 EDT
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.
Comment 1 Harald Hoyer 2010-08-18 03:30:30 EDT
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?
Comment 2 Denis Arnaud 2010-08-18 06:29:08 EDT
(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...]
Comment 3 Harald Hoyer 2010-08-18 08:37:47 EDT
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!!
Comment 4 Denis Arnaud 2010-08-18 16:50:34 EDT
(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.
Comment 5 Denis Arnaud 2010-08-18 17:53:44 EDT
(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)?
Comment 6 Denis Arnaud 2010-08-18 19:00:03 EDT
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.
Comment 7 Gene Snider 2010-08-18 20:37:25 EDT
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
Comment 8 Harald Hoyer 2010-08-19 05:45:15 EDT
(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
Comment 9 Denis Arnaud 2010-08-19 17:35:54 EDT
(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!
Comment 10 Denis Arnaud 2010-08-20 04:02:54 EDT
Bug #624641 has been reopened, as it was fixed with boost-1.44.0-0.6.
Comment 11 Denis Arnaud 2010-08-20 06:31:15 EDT
(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?
Comment 12 Denis Arnaud 2010-08-21 13:03:55 EDT
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.
Comment 13 Denis Arnaud 2010-08-21 13:17:24 EDT
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.
Comment 14 Denis Arnaud 2010-08-21 14:09:04 EDT
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
Comment 15 Fedora Update System 2010-08-22 06:14:28 EDT
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
Comment 16 Denis Arnaud 2010-08-23 03:32:09 EDT
Hugin successfully built on Fedora Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=191494
Comment 17 Denis Arnaud 2010-08-23 08:45:04 EDT
And on Fedora 14: http://koji.fedoraproject.org/koji/taskinfo?taskID=2418063
Comment 18 Fedora Update System 2010-08-23 15:03:55 EDT
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
Comment 19 Fedora Update System 2010-08-23 15:18:19 EDT
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
Comment 20 Gene Snider 2010-08-23 21:35:08 EDT
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
Comment 21 leigh scott 2010-08-24 13:46:18 EDT
(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.
Comment 22 Gene Snider 2010-08-24 16:05:02 EDT
Thanks Leigh, I see you switched the component in my bug report.

Gene
Comment 23 Denis Arnaud 2010-08-24 16:42:19 EDT
(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.
Comment 24 Gene Snider 2010-08-24 18:25:08 EDT
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
Comment 25 leigh scott 2010-08-25 01:33:03 EDT
(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?
Comment 26 Rex Dieter 2010-08-25 09:47:45 EDT
per comment #25 , i've tagged this for buildroot override, see also
https://fedorahosted.org/rel-eng/ticket/4003
Comment 27 Fedora Update System 2010-08-25 23:26:30 EDT
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.
Comment 28 Fedora Update System 2010-08-26 15:27:36 EDT
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
Comment 29 Fedora Update System 2010-09-01 01:54:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.