abrt version: 1.1.13 architecture: i686 Attached file: backtrace cmdline: /usr/bin/gtk-gnash -u http://s.ytimg.com/yt/swf/watch-vfl184368.swf -U http://www.youtube.com/watch?v=5XPe8_YHfN0&feature=popular -x 125829184 -j 640 -k 385 -F 17:18 -P allowfullscreen=true -P allowscriptaccess=always -P bgcolor=#000000 -P flashvars=rv.7.length_seconds=43&rv.2.thumbnailUrl=http%3A%2F%2Fi4.ytimg.com%2Fvi%2FsUNCRrQTvD8%2Fdefault.jpg&rv.0.url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D8ypzvm9i6ds&rv.0.view_count=161&enablecsi=1&rv.2.title=Revenue%20Share%20On%20My%20Videos&vq=auto&rv.6.author=TheLostLake&rv.3.view_count=1303&rv.0.length_seconds=104&rv.4.thumbnailUrl=http%3A%2F%2Fi3.ytimg.com%2Fvi%2FJrsnIJm2x1Q%2Fdefault.jpg&fmt_url_map=22%7Chttp%3A%2F%2Fv24.lscache3.c.youtube.com%2Fvideoplayback%3Fip%3D0.0.0.0%26sparams%3Did%252Cexpire%252Cip%252Cipbits%252Citag%252Cratebypass%252Coc%253AU0dXR1ZPUl9FSkNNN19OSVZB%26fexp%3D900035%252C901022%26itag%3D22%26ipbits%3D0%26sver%3D3%26ratebypass%3Dyes%26expire%3D1282644000%26key%3Dyt1%26signature%3DC3C8569A349FAFBC46765BCD2089E03CA26254D8.46FBF4019CD80ACED0688556E8C422CA6863F94B%26id%3De573def3f6077cdd%2C35%7Chttp%3A%2F%2Fv12.lscache8.c.youtube.com%2Fvideoplayback%3Fip%3D0.0.0.0%26sparams%3Did%252Cexpire%252Cip%252Cipbits%252Citag%252Calgorithm%252Cburst%252Cfactor%252Coc%253AU0dXR1ZPUl9FSkNNN19OSVZB%26fexp%3D900035%252C901022%26algorithm%3Dthrottle-factor%26itag%3D35%26ipbits%3D0%26burst%3D40%26sver%3D3%26expire%3D1282644000%26key%3Dyt1%26signature%3DC90A34C4F3832DBBD9DD658B956AA7FCD63CD5D9.3103DC3B9B201735C69B1E798DACB475DC303353%26factor%3D1.25%26id%3De573def3f6077cdd%2C34%7Chttp%3A%2F%2Fv22.lscache6.c.youtube.com%2Fvideoplayback%3Fip%3D0.0.0.0%26sparams%3Did%252Cexpire%252Cip%252Cipbits%252Citag%252Calgorithm%252Cburst%252Cfactor%252Coc%253AU0dXR1ZPUl9FSkNNN19OSVZB%26fexp%3D900035%252C901022%26algorithm%3Dthrottle-factor%26itag%3D34%26ipbits%3D0%26burst%3D40%26sver%3D3%26expire%3D1282644000%26key%3Dyt1%26signature%3D780D45E651EAC4616E7B30C5DD5F8646A4BF88BF.0F6C74475F497D824354FA292D9A376F04461291%26factor%3D1.25%26id%3De573def3f6077cdd%2C5%7Chttp%3A%2F% component: gnash crash_function: boost::thread::start_thread() executable: /usr/bin/gtk-gnash kernel: 2.6.35.2-9.fc14.i686 package: gnash-1:0.8.8-1.fc14 rating: 4 reason: Process /usr/bin/gtk-gnash was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1282621531 uid: 500 How to reproduce ----- 1.Install gnash and gnash-plugin 2.Open a youtube video 3.See the crash
Created an attachment (id=440551) File: backtrace
Oh "wonderful" (not!), looks like YouTube is still hit or miss with 0.8.8. :-( I have seen quite some bizarre behavior with gnash-klash-0.8.8 on YouTube in the little testing I did so far.
*** Bug 626730 has been marked as a duplicate of this bug. ***
Bug 626730 has a better backtrace: https://bugzilla.redhat.com/attachment.cgi?id=440600 (The one attached to this bug is missing debugging information for some reason.)
Folks, have you tried clearing your YouTube cookies?
I even tried it with in a new user account. It still crashes the same.
This is definitly a boost-1.44.0 bug since gnash-0.8.8 works on F-13 without issues.
OK, reassigning. Boost maintainers, can you please check what's going on here? Gnash 0.8.8 works with F13's Boost 1.41.0, but crashes somewhere inside boost::thread, in code inlined from boost::smart_ptr, with F14's Boost 1.44.0.
yes, the change occured between boost-1.44.0-0.5 and boost-1.44-0-0.6. downgrading to boost-1.44.0-0.5 fixes the crash
Yes, that is an issue with Boost-1.44.0 on Fedora 14. See my comments here: https://bugzilla.redhat.com/show_bug.cgi?id=624937#c23 In short, there is a mis-alignment issue: boost-1.44.0-0.5 was a release candidate, and the code somewhat differs from the final released one (available in boost-1.44.0-0.6 and boost-1.44.0-1). The problem is that the massive rebuild has been done with boost-1.44.0-0.5. The only solution is to do a massive rebuild again, this time based on boost-1.44.0-1 (it should occur soon, I guess). In the meantime, the work-around is to rebuild your own package on top of boost-1.44.0-1 (which is in the testing repository of F14). For instance, it worked for qbittorrent (https://bugzilla.redhat.com/show_bug.cgi?id=624937#c24). Note that there is no problem on Rawhide, as boost-1.44.0-0.6 has been the default version for over a week, and almost all of the packages have been rebuilt against that version.
Package: gnash-1:0.8.8-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Start Gnash viewer from the menu 2. Crash
(In reply to comment #8) boost-1.44.0-1 has been tagged as "buildroot override" (see also https://bugzilla.redhat.com/show_bug.cgi?id=624937#c26), meaning that, if rebuilt now, gnash will be rebuilt against that version (boost-1.44.0-1). Kevin, could you rebuild gnash on F14 (and check that boost-1.44.0-1 is used)?
*** Bug 627225 has been marked as a duplicate of this bug. ***
Don't we all love silent ABI changes? (Hooray for development versions with unstable ABI…) :-( So in short: * gnash-1:0.8.8-1.fc14 requires boost-1.44.0-0.5.fc14. It will crash with newer builds. * I will shortly build a gnash-1:0.8.8-1.fc14.1 against boost-1.44.0-1.fc14 which will work with current builds (>= boost-1.44.0-0.6.fc14 including hopefully all the final 1.44.0 builds). It will most likely crash with the old boost-1.44.0-0.5.fc14 which is still in the stable dist-f14.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2426594
(In reply to comment #15) > http://koji.fedoraproject.org/koji/taskinfo?taskID=2426594 I also tried to rebuild it on Koji (http://koji.fedoraproject.org/koji/taskinfo?taskID=2426563), but the info source file seem to be missing: ---------- /usr/bin/makeinfo --force gnash_user.texi gnash_user.texi: No such file or directory make[3]: Leaving directory `/builddir/build/BUILD/gnash-0.8.8/doc/C' make[3]: [gnash_user.info] Error 1 (ignored) make[3]: *** No rule to make target `gnash_ref.texi', needed by `gnash_ref.info'. Stop. ----------
Yeah, my build failed with the same issue. It's unrelated to Boost. It seems docbook2texi has become stricter: docbook2texi://book[@id='index']: no description for directory entry docbook2texi://table[@id='tb-command-line-options']/tgroup/tbody/row[15]/entry[2]/itemizedlist: non-inline content not supported docbook2texi://table[@id='tb-config-variables']/tgroup/tbody/row[27]/entry[3]/programlisting: non-inline content not supported
The thing is, docbook2texi hasn't changed at all since the successful build, and I didn't change anything in Gnash in that area either (the ONLY thing I did was to bump Release and add a corresponding %changelog entry).
Does that mean that, for now, an older version of gnash (0.8.7-5) sould be built on F14?
No. Chances are it would fail exactly the same way. Again, this breakage is NOT caused by a change in Gnash.
Note that on my F13, "make" does not trigger any error in the doc sub-directory. So, I've run manually the following commands: basefile="gnashuser"; \ db2x_xsltproc -s texi gnashuser.xml --output {basefile}.txml; \ db2x_texixml --info --encoding=us-ascii//TRANSLIT ${basefile}.txml ; \ rm ${basefile}.txml which does not generate the .texi file, thus triggering the error. Also, the db2x_xsltproc man page reads: "In its earlier versions (< 0.8.4), docbook2X required XSLT extensions to run, and db2x_xsltproc was a special libxslt-based processor that had these extensions compiled-in. When the requirement for XSLT extensions was dropped, db2x_xsltproc became a Perl script which translates the options to db2x_xslt-proc to conform to the format accepted by the stock xsltproc(1) which comes with libxslt. The prime reason for the existence of this script is backward compatibility with any scripts or make files that invoke docbook2X." So, should we understand that that way of using DocBook2X is deprecated?
So what I suspect is going on is that something in the docbook2X toolchain (Gnash is actually using the db2x_* tools, not the docbook-utils ones) (somewhere in its dependency chain) needs to be rebuilt for the new Boost or it will silently generate wrong output and/or give bogus errors on valid output. I compared the root.log files for 0.8.8-1.fc14 (success) and 0.8.8-1.fc14.1 (failure) and at first sight the only significant difference appears to be Boost.
Sorry, I mean "give bogus errors on valid input", not "output".
Oh, and the fact that this way of working is deprecated is entirely irrelevant (it's something to take upstream), what matters is that it suddenly stopped working for no apparent reason.
At the same time, the manual page of docbook2texi reads: "For the moment, jw does not handle XML, but only SGML." So, I do not see how to do otherwise (there is also xsltproc, but it is not clear how to use it in our case).
Oh, I think I see what changed. It's the new make. (The previous buildroot had make-1:3.81-20.fc14, the new one has make-1:3.82-1.fc14 instead.) Old log (success): docbook2texi://book[@id='index']: no description for directory entry docbook2texi://table[@id='tb-command-line-options']/tgroup/tbody/row[15]/entry[2]/itemizedlist: non-inline content not supported docbook2texi://table[@id='tb-config-variables']/tgroup/tbody/row[27]/entry[3]/programlisting: non-inline content not supported /usr/bin/makeinfo --force gnash_user.texi gnash_user.texi: No such file or directory make[5]: [gnash_user.info] Error 1 (ignored) if test x != x; then \ out=`echo gnashref | sed -e 's:gnash:gnash_:'`; \ --encoding=us-ascii//TRANSLIT --string-param directory-description="Gnash" --string-param output-file=${out} gnashref.xml; \ /usr/bin/makeinfo --force ${out}.texi; \ else \ basefile="gnashref"; \ /usr/bin/db2x_xsltproc -s texi gnashref.xml --output ${basefile}.txml; \ /usr/bin/db2x_texixml --info --encoding=us-ascii//TRANSLIT ${basefile}.txml ; \ rm ${basefile}.txml; \ fi docbook2texi://book[@id='index']: no description for directory entry docbook2texi://table[@id='tb-config-features']/tgroup/tbody/row[6]/entry[2]/variablelist: non-inline content not supported docbook2texi://table[@id='tb-config-features']/tgroup/tbody/row[8]/entry[2]/para[2]: non-inline content not supported mkdir -p -- /builddir/build/BUILDROOT/gnash-0.8.8-1.fc14.x86_64/usr/share/info and then it proceeds to install stuff. New log (failure): docbook2texi://book[@id='index']: no description for directory entry docbook2texi://table[@id='tb-command-line-options']/tgroup/tbody/row[15]/entry[2]/itemizedlist: non-inline content not supported docbook2texi://table[@id='tb-config-variables']/tgroup/tbody/row[27]/entry[3]/programlisting: non-inline content not supported /usr/bin/makeinfo --force gnash_user.texi gnash_user.texi: No such file or directory make[3]: Leaving directory `/builddir/build/BUILD/gnash-0.8.8/doc/C' make[3]: [gnash_user.info] Error 1 (ignored) make[3]: *** No rule to make target `gnash_ref.texi', needed by `gnash_ref.info'. Stop. make[3]: Entering directory `/builddir/build/BUILD/gnash-0.8.8/doc' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/builddir/build/BUILD/gnash-0.8.8/doc' make[2]: Leaving directory `/builddir/build/BUILD/gnash-0.8.8/doc' make[2]: *** [all-recursive] Error 1 It looks like Gnash is relying on make -k to ignore errors during the docbook generation and make's behavior for -k changed in 3.82.
So, we can maybe de-activate the refmanual document generation (since, nevertheless, it appears not to be generated), by removing the refmanual entry from the Makefile.am (I'm not sure, but the "info" in line #131 seems a good candidate).
Package: gnash-1:0.8.8-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. load any html-page in firefox with flash movie 2. watch it crash :/ Comment ----- i have gnash in "do not play till i tell you to"-mode. it crashes before i can say it should play the swf movie.
Package: gnash-1:0.8.8-1.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Open in epiphany http://skoob.com.br 2. Gnash will stop 3.
Kevin and I are looking at fixing that bug as soon as possible. Thanks for your understanding.
So, here's some fun configure fail which might explain at least the "no description for directory entry" errors: 1. In doc/C/Makefile.am, there are 2 codepaths for Docbook to texi conversion: -if test x$(DB2X_TEXI) != x; then \ out=`echo $* | sed -e 's:gnash:gnash_:'`; \ $(DB2X_TEXI) --encoding=us-ascii//TRANSLIT --string-param directory-description="Gnash" --string-param output-file=$${out} $<; \ $(MAKEINFO) --force $${out}.texi; \ else \ basefile="$*"; \ $(DB2X_XSLTPROC) -s texi $< --output $${basefile}.txml; \ $(DB2X_TEXIXML) --info --encoding=us-ascii//TRANSLIT $${basefile}.txml ; \ rm $${basefile}.txml; \ fi You'll notice that only the first one appears to set directory-description correctly. 2. This is how macros/docbook.m4 checks for DB2X_TEXI: dnl Find the programs we need to convert docbook into Texi for dnl making info pages. The first catagory are the wrapper dnl utilities included in most docbook2x packages. dnl It turns out there are two sets of wrapper functions, the good dnl ones from the newer DocBook2X tools are written in perl, and dnl actually work correctly. There are other versions of the same dnl tools ,but they are merely a 1 line wrapper for the OpenJade dnl tools. These versions have big problems, namely they don't dnl support the encoding of entities, so we get massive warnings dnl about entities in included files we never heard about. scripts="db2x_docbook2texi docbook2texi docbook2texi.pl" for i in $scripts; do AC_PATH_PROG(DB2X_TEXI, $i, [], [$PATH:/usr/bin:/usr/bin/X11:/usr/local/X11/bin]) if test x$DB2X_TEXI != x; then type="`file $DB2X_TEXI | grep -ic " perl " 2>&1`" if test $type -gt 0; then break else DB2X_TEXI= fi fi done dnl These look for the seperate utilities used by the wrapper dnl scripts. If we don't find the wrappers, then we use the lower dnl level utilities directly. scripts="db2x_texixml db2x_texixml.pl" for i in $scripts; do AC_PATH_PROG(DB2X_TEXIXML, $i, [], [$PATH:/usr/bin:/usr/bin/X11:/usr/local/X11/bin]) if test x$DB2X_TEXIXML != x; then break fi done 3. However, file /usr/bin/db2x_docbook2texi on Fedora returns: /usr/bin/db2x_docbook2texi: a /usr/bin/perl script text executable which doesn't match " perl ".
I'm now checking if this fixes the build. Rawhide build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2429966 Will submit F14 if Rawhide succeeds.
Still fails on F14, due to the 2 remaining errors (the issues with the tables). :-( Looks like Rawhide has an older make than F14, grrr…
Package: gnash-1:0.8.8-1.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Enable plugins in Epiphany 2. Go to a web site with flash (those damned adverts for instance) Comment ----- Gnash just crashes when there is a flash object on any page in Epiphany
(In reply to comment #33) Note that on my (up-to-date) Fedora 14 i686, when just unpacking the upstream source tar-ball and: * launching the ./configure script (without option), it fails on KDE4 detection (at mentioned in the RPM specification file, indeed); * launching first the ./autogen.sh then the ./configure script, it works without problem (and the build in doc/C also works). So, maybe the RPM specification file could be much simplified on Fedora 14?
Created attachment 441821 [details] Patch of the Autotools for Fedora 14 Allows the configure script to run without warning and error on Fedora 14.
Created attachment 441822 [details] RPM specification corresponding to the Autotools patch RPM specification corresponding to the Autotools patch
A build has been done on Koji for the attached RPM specification (the accompanying patch is also provided as attachment): http://koji.fedoraproject.org/koji/taskinfo?taskID=2434037 Unfortunately, it still fails at the same place (Texi files). Maybe the same approach could be used with Rawhide (running ./autogen.sh on Rawhide, and creating the corresponding patch)?
> So, maybe the RPM specification file could be much simplified on Fedora 14? It doesn't really simplify anything. It just allows you to patch the true source instead of sedding the generated files… > Patch of the Autotools for Fedora 14 … but then you don't even do that! I already have a fix for that particular issue! Please see the stuff in my devel branch. > Unfortunately, it still fails at the same place (Texi files). Maybe the same > approach could be used with Rawhide (running ./autogen.sh on Rawhide, and > creating the corresponding patch)? The Rawhide build only succeeds because Rawhide's make is out of date compared to F14. Please do not try to fix something without understanding what's actually going wrong! For this reason, I am NOT granting you your ACL requests to my package.
(In reply to comment #39) > > Patch of the Autotools for Fedora 14 > … but then you don't even do that! I did not hide that it still does not build successfully on F14. My purpose was just to give some ideas on ways to go forward. Since the issue seems to come from the version of make, trying with a fresh configure script seemed, a priori, not so bad an idea. > I already have a fix for that particular issue! Please see the stuff in my > devel branch. Of course, I saw all that. That's why I mentioned "simplifying" the RPM specification file; indeed, some of those work-arounds/fixes may have become less useful on newer versions of the Autotools. > Please do not try to fix something without understanding what's actually going > wrong! "When it works, do not fix it!" I did not intend to commit that version of the package as, as I stated, it does not work yet. And, as I repeat, my intention was only to give some food for thoughts, not to commit anything which does not work.
> indeed, some of those work-arounds/fixes may have become less useful on newer > versions of the Autotools. AFAICT, they're all still needed with the current autotools. Please trust the maintainer of the package to know what he's doing. And if you want to regenerate configure, do it properly (i.e. patch the actual sources and rerun autoconf in the specfile)!
Package: gnash-1:0.8.8-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Installed gnash and gnash-plugin 2. Went to 'about:plugins' in firefox browser to check it registers. 3. Got a crash message from ABRT.
*** This bug has been marked as a duplicate of bug 629972 ***
it is a typo in doc generation, what I did is : sed -i 's|gnashref.texi gnash_user.texi|gnashref.texi gnash_ref.texi|g' doc/C/Makefile.in here is a scratch build : http://koji.fedoraproject.org/koji/taskinfo?taskID=2507831
This is NOT a duplicate of bug 629972, the backtraces are completely different! And bug 629972 is on F13, which is not affected by this issue at all! Denis Arnaud, please refrain from touching Gnash bugs in the future. You may be an expert on Boost, but you seem to be very unfamiliar with Gnash.
(And why is this assigned to Boost? It's Gnash needing a rebuild. Reassigning.)
gnash-0.8.8-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gnash-0.8.8-3.fc14
Package: gnash-1:0.8.8-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Go to http://svtplay.se/
gnash-0.8.8-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.