Bug 626664 - [abrt] gnash-1:0.8.8-1.fc14: boost::thread::start_thread(): Process /usr/bin/gtk-gnash was killed by signal 11 (SIGSEGV)
Summary: [abrt] gnash-1:0.8.8-1.fc14: boost::thread::start_thread(): Process /usr/bin/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnash
Version: 14
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kevin Kofler
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:bd2782ae5a2ad822bc36fd7ad17...
: 626730 627225 (view as bug list)
Depends On: 631181
Blocks: F14Target
TreeView+ depends on / blocked
 
Reported: 2010-08-24 03:47 UTC by Hicham HAOUARI
Modified: 2010-10-15 13:33 UTC (History)
17 users (show)

Fixed In Version: gnash-0.8.8-4.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-15 13:33:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (19.30 KB, text/plain)
2010-08-24 03:47 UTC, Hicham HAOUARI
no flags Details
Patch of the Autotools for Fedora 14 (89.89 KB, application/x-bzip)
2010-08-29 18:55 UTC, Denis Arnaud
no flags Details
RPM specification corresponding to the Autotools patch (17.82 KB, text/plain)
2010-08-29 18:56 UTC, Denis Arnaud
no flags Details

Description Hicham HAOUARI 2010-08-24 03:47:42 UTC
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

Comment 1 Hicham HAOUARI 2010-08-24 03:47:45 UTC
Created an attachment (id=440551)
File: backtrace

Comment 2 Kevin Kofler 2010-08-24 03:51:10 UTC
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.

Comment 3 Kevin Kofler 2010-08-24 13:28:15 UTC
*** Bug 626730 has been marked as a duplicate of this bug. ***

Comment 4 Kevin Kofler 2010-08-24 13:29:37 UTC
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.)

Comment 5 Kevin Kofler 2010-08-24 13:38:02 UTC
Folks, have you tried clearing your YouTube cookies?

Comment 6 Michal Schmidt 2010-08-24 14:49:45 UTC
I even tried it with in a new user account. It still crashes the same.

Comment 7 Hicham HAOUARI 2010-08-25 04:48:16 UTC
This is definitly a boost-1.44.0 bug since gnash-0.8.8 works on F-13 without issues.

Comment 8 Kevin Kofler 2010-08-25 05:09:06 UTC
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.

Comment 9 Hicham HAOUARI 2010-08-25 05:16:24 UTC
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

Comment 10 Denis Arnaud 2010-08-25 08:28:46 UTC
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.

Comment 11 Javier Jardón 2010-08-25 16:05:56 UTC
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

Comment 12 Denis Arnaud 2010-08-25 17:07:01 UTC
(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)?

Comment 13 Kevin Kofler 2010-08-25 18:02:04 UTC
*** Bug 627225 has been marked as a duplicate of this bug. ***

Comment 14 Kevin Kofler 2010-08-25 18:09:40 UTC
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.

Comment 16 Denis Arnaud 2010-08-25 18:47:18 UTC
(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.
----------

Comment 17 Kevin Kofler 2010-08-25 18:57:44 UTC
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

Comment 18 Kevin Kofler 2010-08-25 19:03:36 UTC
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).

Comment 19 Denis Arnaud 2010-08-25 19:04:37 UTC
Does that mean that, for now, an older version of gnash (0.8.7-5) sould be built on F14?

Comment 20 Kevin Kofler 2010-08-25 19:31:32 UTC
No. Chances are it would fail exactly the same way. Again, this breakage is NOT caused by a change in Gnash.

Comment 21 Denis Arnaud 2010-08-25 19:35:12 UTC
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?

Comment 22 Kevin Kofler 2010-08-25 19:40:53 UTC
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.

Comment 23 Kevin Kofler 2010-08-25 19:41:59 UTC
Sorry, I mean "give bogus errors on valid input", not "output".

Comment 24 Kevin Kofler 2010-08-25 19:43:35 UTC
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.

Comment 25 Denis Arnaud 2010-08-25 19:47:41 UTC
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).

Comment 26 Kevin Kofler 2010-08-25 19:49:54 UTC
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.

Comment 27 Denis Arnaud 2010-08-25 19:55:36 UTC
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).

Comment 28 Tobias Florek 2010-08-25 21:56:19 UTC
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.

Comment 29 cleiton Lima 2010-08-26 02:49:09 UTC
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.

Comment 30 Denis Arnaud 2010-08-26 21:14:46 UTC
Kevin and I are looking at fixing that bug as soon as possible. Thanks for your understanding.

Comment 31 Kevin Kofler 2010-08-26 22:07:28 UTC
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 ".

Comment 32 Kevin Kofler 2010-08-26 22:15:53 UTC
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.

Comment 33 Kevin Kofler 2010-08-26 23:28:24 UTC
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…

Comment 34 Bruce Cowan 2010-08-27 00:00:04 UTC
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

Comment 35 Denis Arnaud 2010-08-27 23:13:18 UTC
(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?

Comment 36 Denis Arnaud 2010-08-29 18:55:30 UTC
Created attachment 441821 [details]
Patch of the Autotools for Fedora 14

Allows the configure script to run without warning and error on Fedora 14.

Comment 37 Denis Arnaud 2010-08-29 18:56:44 UTC
Created attachment 441822 [details]
RPM specification corresponding to the Autotools patch

RPM specification corresponding to the Autotools patch

Comment 38 Denis Arnaud 2010-08-29 19:00:52 UTC
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)?

Comment 39 Kevin Kofler 2010-08-30 11:04:07 UTC
> 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.

Comment 40 Denis Arnaud 2010-08-30 14:09:16 UTC
(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.

Comment 41 Kevin Kofler 2010-08-30 17:03:06 UTC
> 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)!

Comment 42 Luke Bigum 2010-09-04 19:14:33 UTC
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.

Comment 43 Denis Arnaud 2010-09-05 12:14:37 UTC

*** This bug has been marked as a duplicate of bug 629972 ***

Comment 44 Hicham HAOUARI 2010-10-02 10:47:35 UTC
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

Comment 45 Kevin Kofler 2010-10-02 11:51:30 UTC
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.

Comment 46 Kevin Kofler 2010-10-02 11:54:34 UTC
(And why is this assigned to Boost? It's Gnash needing a rebuild. Reassigning.)

Comment 47 Fedora Update System 2010-10-02 12:45:06 UTC
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

Comment 48 Mattias Ellert 2010-10-02 19:44:09 UTC
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/

Comment 49 Fedora Update System 2010-10-15 12:42:56 UTC
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.


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