Bug 204283 - firefox closes on most (all?) websites with flash enabled
firefox closes on most (all?) websites with flash enabled
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnash (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE7Target
  Show dependency treegraph
 
Reported: 2006-08-28 04:33 EDT by Sander Hoentjen
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.7.2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-27 09:03:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Sander Hoentjen 2006-08-28 04:33:18 EDT
Description of problem:
With gnash-plugin installed firefox closes when you visit a website with flash
content

Version-Release number of selected component (if applicable):
# rpm -qa |grep gnash
gnash-plugin-0.7.1-7.fc6
gnash-0.7.1-7.fc6

How reproducible:
always

Steps to Reproduce:
1. install gnash, gnash-plugin (got them from buildsys, so they are not signed
yet but otherwise should be the same as the ones that will appear in the extas repo)
2. start firefox
3. go to the url: http://mirrors.creativecommons.org/getcreative/
  
Actual results:
firefox is closed

Expected results:
view some flash movie

Additional info:
I removed ~/.mozilla and tried again but i got the same results

Is there anyway I can give you a more detailed bug report, any way to get a
trace or something?
Comment 1 Sander Hoentjen 2006-08-28 04:34:37 EDT
whoops didn't choose my hardware platform
Comment 2 Patrice Dumas 2006-08-28 05:04:17 EDT
Firs of all it is not unexpected that gnash crashes on most flash,
it is even warned in the rpm description. However it shouldn't crash 
on all. Could you find some where gnash didn't crash?

Regarding bug reports, first thing to know is that the gnash packaged 
in fedora extra is now very different than the upstream cvs version,
which is moving very fast. So if you want to help debug gnash, it may 
be more usefull to get the gnash cvs version and rebuild it (even though
it might be not that easy). 

To debug gnash, the first thing to do, in my opinion is to try the
standalone viewer on the flash file gnash downloaded. In the fedora
version it is downloaded in 
/tmp/gnash-XXXXX

Then start gnash on that file, and, if it crash you can report 
gnash -va -vp /tmp/gnash-XXXXX/thefile.swf

If it is a crash that happens only in browser, I know there is a way 
to debug that but I'll have to see the gnash list, or ask there. But
most of the time the standalone gnash also crashes and give more 
information.
Comment 3 Patrice Dumas 2006-08-28 06:04:08 EDT
I've just tested that this film works quite well with gnash 
cvs version.
Comment 4 Sander Hoentjen 2006-08-28 08:50:07 EDT
Any chance you will package the CVS version or will you wait until next release?
Comment 5 Sander Hoentjen 2006-08-28 09:46:33 EDT
Oh and to answer your question: I didn't find one yet where it didn't crash. Can
you point me to one?

After wednesday i might have some time to try out cvs. 
Comment 6 Patrice Dumas 2006-08-28 10:11:33 EDT
(In reply to comment #4)
> Any chance you will package the CVS version or will you wait until next release?

Currently the CVS version is moving very fast, so I think it is
not a very good idea to package it.
Comment 7 Sander Hoentjen 2006-08-28 10:55:07 EDT
(In reply to comment #6)
> Currently the CVS version is moving very fast, so I think it is
> not a very good idea to package it.
Ok, I understand.

I tested a bit further and it seems the flash files don't even get downloaded (i
have no /tmp/gnash-*)
If I download the files with wget i have no problems playing them with gnash, so
something else must be wrong. If you can find how I can debug this I would be
grateful, I tried searching the gnash-list archives but it seems my searching
abilities are not up to it.
Comment 8 Patrice Dumas 2006-08-29 11:17:50 EDT
I have tested with an i386, and it works (but stops
before thet cvs version...).
.
Comment 9 Patrice Dumas 2006-08-29 11:25:54 EDT
To help debugging this issue, you could first install 
firefox-debuginfo, and launch gnash with  ?waitforgdb=yes 
on the url.

Here is a excerpt of a mail:
"Are you running a debug build of Firefox, and then starting it with -g. With
Gnash, you can also invoke the Flash movie and add "?waitforgdb=yes", and the
plugin will block in the very being of it's initialization. Then you can attach
GDB, and set breakpoints in that instance."

I also saw on another mail that firefox may be started with --sync, maybe 
it helps debugging.
Comment 10 Sander Hoentjen 2006-11-01 04:40:28 EST
Ok after some time of silence I would like to say that I still have the problem.
Now I started with firefox -g and it gives me:

10:37:10: xEmbed supported in this Mozilla version
10:37:10: Gtk2+ supported in this Mozilla version
10:37:10: TRACE: nsPluginInstanceBase* NS_NewPluginInstance(nsPluginCreateData*)
enter
10:37:10: TRACE: nsPluginInstance::nsPluginInstance(NPP_t*) enter
10:37:10: TRACE: virtual NPError nsPluginInstance::GetValue(NPPVariable, void*):
enter for instance 0x1901510
10:37:10: TRACE: NPError NS_PluginGetValue(NPPVariable, void*) enter
10:37:10: TRACE: virtual NPError nsPluginInstance::SetWindow(NPWindow*): enter
for instance 0x1901510
10:37:10: SetWindow: X origin = 0, Y Origin = 0, Width = 1270, Height = 833,
WindowID = 0x4400f81, this = 0x1901510
10:37:10: TRACE: void nsPluginInstance::lockGL(): for instance 0x1901510
10:37:10: TRACE: void nsPluginInstance::lockX(): for instance 0x1901510
10:37:10: SetWindow: Got new glxContext 0x1b573f8
10:37:10: TRACE: void nsPluginInstance::setGL(): gxDisplay = 0x18ff930, _window
= 0x4400f81, _glxContext = 0x1b573f8 for instance 0x1901510
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 26 error_code 8 request_code 145 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Program exited with code 01.
(gdb)

It looks the same wether I put ?waitforgdb=yes in the URL or not.
Anything else I can do to help?
Comment 11 Sander Hoentjen 2006-11-01 05:01:02 EST
i found this: https://savannah.gnu.org/bugs/?func=detailitem&item_id=15925
So it is most probably fixed in cvs, I don't have time to check it out though
Comment 12 Patrice Dumas 2006-11-01 05:06:55 EST
The new vresion is due very soon, it is much better. 
maybe you can wait and retest with that version?
Comment 13 Sander Hoentjen 2006-11-01 07:31:47 EST
sure, can you post here when a new version is available?
Comment 14 Patrice Dumas 2006-11-01 07:48:57 EST
of course.
Comment 15 Bryan Christ 2006-11-10 11:30:18 EST
The new version is needed urgently.  Gnome has crashed on me many times because
of this bug (When gnash crashes firefox it takes everything down with it). 
According to the gnash bug db, this is fixed upstream.  Their bug ID is 16568. 
I am using Fedora Core 5 and gnash is 7.1
Comment 16 Bryan Christ 2006-11-10 11:32:46 EST
Since not only Firefox crashes, but all of Gnome, I would suggest this bug be
set to urgent.
Comment 17 Patrice Dumas 2006-11-10 11:53:28 EST
If all gnome crashes it is not only a gnash bug. gnash shouldn't be
able to crash gnome. It maybe a mesa, or an X bug. This was an issue
in fedora core 5, but on fedora core 6 I had much less problems
with X crashing. 

Anyway the 7.0.2 release certainly fixes many issues/crashes (and I am
seriously considering switching from the opengl based renderer to the 
agg based), but it is still not ready (still some bugs to clean and
also licencing issues). As soon as it is released I'll update gnash and 
I'll let you know in that bug.

There is a disclaimer in the rpm %description, gnash is known to 
crash X:

Note that Gnash does not work yet for newer flash sites, is known to
crash and can even trigger bugs that crash the graphical system.
Comment 18 Bryan Christ 2006-11-10 12:31:27 EST
Well I can say for sure that it's not crashing X because my session remains. 
Gnome Panel and the gnome-appelets survive, but Nautilus and all of my
applications die.  Also, I am not using any 3D acceleration (like Mesa) but just
the standard mga X server.
Comment 19 Patrice Dumas 2006-11-10 12:41:24 EST
(In reply to comment #18)
> Well I can say for sure that it's not crashing X because my session remains. 
> Gnome Panel and the gnome-appelets survive, but Nautilus and all of my
> applications die.  Also, I am not using any 3D acceleration (like Mesa) but just
> the standard mga X server.

gnash do use Mesa, through opengl (through gtkglext). Anyway it may also 
be a bug in the display manager or any other gnome component, but gnash 
shouldn't be able to kill Nautilus, or anything else it doesn't share
memory with. It should only be able to crash firefox, anything else
crashing is related with a bug somewhere else than in gnash. (Of course 
that bug is certainly triggered by a gnash bug).
Comment 20 Bryan Christ 2006-11-10 13:12:48 EST
I noticed an interesting difference in behavior.  If you open the offending
webpage directly, only Firefox crashes.  However, if you open the page with the
"open in new tab" feature and tabs are set to open in the background all of the
applications crash.

Correction:  Gnome panel does crash.
Comment 21 Patrice Dumas 2006-11-21 18:34:37 EST
(In reply to comment #20)
> I noticed an interesting difference in behavior.  If you open the offending
> webpage directly, only Firefox crashes.  However, if you open the page with the
> "open in new tab" feature and tabs are set to open in the background all of the
> applications crash.

Maybe an issue with gtk?
Comment 22 Patrice Dumas 2006-11-21 18:41:35 EST
gnash 0.7.2 is out. It is still alpha but there are many changes,
and much improvements. Maybe your issues are closed? 

It certainly still crashes firefox now and then, there are still 
many flash files that don't show correctly and flv video is still 
unimplemented, it is one of the main focus of developpement currently. 
Also there is a new backend based on agg that I would have liked 
to use, but since the kde plugin doesn't work with the agg backend 
I still use the opengl based backend.

Sound should work if you install gstreamer plugins which handle
mp3.
Comment 23 Bryan Christ 2006-11-22 10:33:42 EST
Do you know where I can find a gnash 0.7.2 rpm package for FC5 and see if the
issue is resolved?
Comment 24 Patrice Dumas 2006-11-23 06:06:44 EST
There has never been a gnash for FG-5, since on that platform there
were a lot of mesa/GL issues and gnash crashed X a lot. I can do 
a release for FC-5 if you really want to. Also maybe the mesa issues
have been solved, I don't know.
Comment 25 Sander Hoentjen 2006-11-24 14:56:35 EST
ok, the issue i reported is fixed, the bug can be closed. Thanks!
Comment 26 Patrice Dumas 2006-11-27 09:03:11 EST
(In reply to comment #23)
> Do you know where I can find a gnash 0.7.2 rpm package for FC5 and see if the
> issue is resolved?

I just made a build of gnash 0.7.2 on FC-5.
Comment 27 Bryan Christ 2006-11-27 10:22:57 EST
It appears to fix the crashing.  I think this can be closed.

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