Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 279202 - www-plugins/adobe-flash-10.0.22.87-r2 (64bit) crashes firefox
Summary: www-plugins/adobe-flash-10.0.22.87-r2 (64bit) crashes firefox
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Jim Ramsay (lack) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on: CVE-2009-1862
Blocks:
  Show dependency tree
 
Reported: 2009-07-26 18:27 UTC by Nico Schlömer
Modified: 2010-01-18 07:49 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Schlömer 2009-07-26 18:27:21 UTC
Hi,

I'm aware of the fact the Adobe's flash player has a long history of vulnerabilities and crashes, and here's just another one.

I'm running on AMD64 instructions here, with Firefox 3.5.1 and www-plugins/adobe-flash-10.0.22.87-r2. Some sites would work pretty well, others not. For example, when I open a video on youtube there's no problem watching it, but upon closing the tab the video is/was shown, Firefox would segfault.

Flash is installed with "64bit -32bit -multilib".

What can I do to debug?

Cheers,
Nico

Reproducible: Always
Comment 1 Wormo (RETIRED) gentoo-dev 2009-07-27 01:00:43 UTC
There isn't much we can help you with debugging binary plugins... it would be good to file a bug report with Adobe though: https://bugs.adobe.com/flashplayer/

Have you already tried running 32-bit flash under nspluginwrapper? It might be a good workaround while you're waiting for Adobe to release a better 64-bit version.
Comment 2 Chí-Thanh Christopher Nguyễn gentoo-dev 2009-07-27 04:36:00 UTC
emerge sys-devel/gdb and start firefox with "-g -d gdb" parameter, then get a gdb backtrace of the crash. If it is in mozilla code, then you could report upstream to https://bugzilla.mozilla.org/
Comment 3 James Earl Spahlinger 2009-07-27 04:48:08 UTC
Using amd64, I failed to replicate this following the following steps:

1. Open youtube, http://youtube.com
2. Click a move.
3. Let it play
4. Close the *tab* while movie is playing (waiting until the end of the movie
also does not produce a crash)

using www-client/mozilla-firefox-bin-3.5.1 and
www-plugins/adobe-flash-10.0.22.87-r2 with default settings/configuration.
Comment 4 Nico Schlömer 2009-07-27 07:24:22 UTC
Hey guys,

thanks for the verbose feedback!

I deleted all the configs in the ~/.* files but still the same thing, so I guess to problem is kind of rare considering the fact that it works perfectly alright for James on the same setup.

I'll report upstream anyway.

Say, a pretty noobish question: When I go `firefox -g -d gdb` it wouldn't give me any traces, but instead load www.gdb.com on startup -- hehe, well.. I reckon firefox needs to be compiled with some debug flag or something?

Cheers,
Nico
Comment 5 James Earl Spahlinger 2009-07-27 10:04:14 UTC
You need to compile firefox with debug flags enabled (eg USE="debug" emerge -vat mozilla-firefox to do a temporary debug flag for firefox (will be forgotten by portage on next emerge of firefox) or echo "www-client/mozilla-firefox debug" >> /etc/make.keywords to have the debug setting always added for firefox).

Once you do that:

emerge -vat gdb               #to emerge the gnu debugger
emerge -vat mozilla-firefox   #recompile firefox with debug flag

Then:

firefox -g -d gdb

Comment 6 James Earl Spahlinger 2009-07-27 10:06:04 UTC
Oh, and apologies for the double "post", but once you get in gdb and you reproduce the crash, you will want to type 'bt' in the gdb prompt to get the backtrace. Copy paste that here as well as on your upstream bug if you suspect the issue is upstream. 
Comment 7 James Earl Spahlinger 2009-07-27 10:10:44 UTC
(In reply to comment #5)
> You need to compile firefox with debug flags enabled (eg USE="debug" emerge
> -vat mozilla-firefox to do a temporary debug flag for firefox (will be
> forgotten by portage on next emerge of firefox) or echo
> "www-client/mozilla-firefox debug" >> /etc/make.keywords to have the debug
> setting always added for firefox).
> 
> Once you do that:
> 
> emerge -vat gdb               #to emerge the gnu debugger
> emerge -vat mozilla-firefox   #recompile firefox with debug flag
> 
> Then:
> 
> firefox -g -d gdb
> 

Oh crap, I gave bad instructions: 

> You need to compile firefox with debug flags enabled (eg USE="debug" emerge
> -vat mozilla-firefox to do a temporary debug flag for firefox (will be
> forgotten by portage on next emerge of firefox) or echo
> "www-client/mozilla-firefox debug" >> /etc/make.keywords to have the debug
> setting always added for firefox).

should be: 

You need to compile firefox with debug flags enabled (eg USE="debug" emerge -vat mozilla-firefox to do a temporary debug flag for firefox (will be forgotten by portage on next emerge of firefox) or echo "www-client/mozilla-firefox debug" >> /etc/portage/make.keywords to have the debug setting always added for firefox).

Apologies for this. 
Comment 8 Nico Schlömer 2009-07-27 10:12:18 UTC
Hi James,

thanks for the instructions. But, hm, well if I see things correctly, www-client/mozilla-firefox doesn't have the 'debug' USE flag at all. -- ?

That may be a shortcoming of the ebuild actually.
Comment 9 James Earl Spahlinger 2009-07-27 12:56:40 UTC
The ebuild www-client/mozilla-firefox has the useflag debug, you can verify this vie gentoo-portage.com as well as locally: http://gentoo-portage.com/www-client/mozilla-firefox/USE#ptabs

Could you post what command you are using to emerge firefox with, as well as the contents of your /etc/portage/package.keywords

Thanks :)
Comment 10 Nico Schlömer 2009-07-27 16:03:48 UTC
Hi,

well, I'm running paludis here, so I guess it might not be terribly useful to post all the portage files here.

The file /etc/paludis/use.conf contains the line
================= *snip* =================
www-client/mozilla-firefox debug
================= *snip* =================
which enables the debug USE flag (if existing). A `paludis -i mozilla-firefox` still won't pull it in, which is I beliebe b/c is is no such flag. -- What is displayed on gentoo-portage.com refers to mozilla-firefox-2.*, there you *do* have debug; it disappeared with 3.*.

Can you confirm?

Cheers,
Nico
Comment 11 Bernd Pachur 2009-07-28 17:26:25 UTC
The problem is not limited to 64bit systems.

I have an ~amd64 system (core 2 duo based) with adobe-flash with multilib use flag using the native 64bit plugin where I did _not_ notice any flash caused firefox crashes.

On the other hand the ~x86 system (athlon64 with march=athlon-xp) _frequently_ crashes when visiting pages that contain flash content.

Both systems have mozilla-firefox-3.5.1 and adobe-flash-10.0.22.87-r2 installed.

I do not have the time at the moment to do some debuging. Nonetheless I think it is important to inform you that there are more problems with adobe-flash.

Cheers,
Bernd
Comment 12 James Earl Spahlinger 2009-07-28 21:01:57 UTC
THere seems to be no debug flag on 3.0.x or 3.5.x, that is a separate issue though from this. 
Comment 13 Jory A. Pratt gentoo-dev 2009-07-31 05:22:06 UTC
(In reply to comment #12)
> THere seems to be no debug flag on 3.0.x or 3.5.x, that is a separate issue
> though from this. 
> 

That is no issue as it is expected that xulrunner useflag is enabled for firefox-3.0.x, in firefox-3.5.x all builds will be forced to xulrunner which is where debugging has to happen.
Comment 14 James Earl Spahlinger 2009-07-31 05:27:28 UTC
Ok, so to get firefox debugging information, what package needs the useflag turned on? xulrunner? Also feel free to re-assign this bug or tell me where its re-assigned. 

P.S. Apologies about that prior bug re cc'ing mozilla@g.o.
Comment 15 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2009-08-02 11:12:07 UTC
Alright, as mentioned by Jory you have to activate the "debug" USE flag in net-libs/xulrunner. You might also take a look at http://www.gentoo.org/proj/en/qa/backtraces.xml which describes how to obtain meaningful backtraces in general.
Comment 16 Nico Schlömer 2009-08-02 19:43:16 UTC
Okay, I compiled xulrunner with 'debug' and indeed I get some info out of it. When accessing certain sites containing flash, Firefox would freeze with

============================ *snip* ============================
Program /usr/lib64/mozilla-firefox/firefox (pid = 8464) received signal 11.
Stack:
UNKNOWN [/lib/libpthread.so.0 +0x0000EA00]
pthread_detach+0x00000004 [/lib/libpthread.so.0 +0x000075E4]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x0068041C]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x00664191]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x004F0FF2]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x004F471C]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x003C1944]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x003CB3EA]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x003B33E1]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x003A8AF0]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x00092D29]
UNKNOWN [/opt/netscape/plugins/libflashplayer.so +0x00082DAF]
UNKNOWN [/usr/lib/libglib-2.0.so.0 +0x0003A02B]
g_main_context_dispatch+0x00000249 [/usr/lib/libglib-2.0.so.0 +0x000398B9]
UNKNOWN [/usr/lib/libglib-2.0.so.0 +0x0003CFA0]
g_main_context_iteration+0x0000006C [/usr/lib/libglib-2.0.so.0 +0x0003D13C]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x013C3934]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x013E3C44]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x013E413A]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x0154BD05]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x014E9506]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x013E4384]
UNKNOWN [/usr/lib64/xulrunner-1.9.1/libxul.so +0x0117D84C]
XRE_main+0x000027E7 [/usr/lib64/xulrunner-1.9.1/libxul.so +0x004A90D5]
UNKNOWN [/usr/lib64/mozilla-firefox/firefox +0x00002505]
__libc_start_main+0x000000E6 [/lib/libc.so.6 +0x0001E5C6]
UNKNOWN [/usr/lib64/mozilla-firefox/firefox +0x00001ED9]
Sleeping for 300 seconds.
Type 'gdb /usr/lib64/mozilla-firefox/firefox 8464' to attach your debugger to this thread.
============================ *snap* ============================

Is that helpful in any way?

Cheers,
Nico
Comment 17 Jim Ramsay (lack) (RETIRED) gentoo-dev 2009-08-03 12:49:08 UTC
Signal 11 is segfault, which may be one of the many "vulnerabilities" listed in bug 278819.  In any case, not much I can do for you with this closed-source sw, except recommend you upgrade to the latest, greatest 10.0.32.18 and cross your fingers.

Comment 18 Nico Schlömer 2009-08-03 14:04:04 UTC
(In reply to comment #17)
Yep, I thought so. Damn' closed source stuff!
Unfortunately, the *32 revision doesn't work for me either. I guess the only thing that remains is filing a bug on bug.adobe.com. :/
Comment 19 Jim Ramsay (lack) (RETIRED) gentoo-dev 2009-08-03 14:23:09 UTC
(In reply to comment #18)
> Yep, I thought so. Damn' closed source stuff!

Amen.

> Unfortunately, the *32 revision doesn't work for me either. I guess the only
> thing that remains is filing a bug on bug.adobe.com. :/

Can you post the contents of your /proc/cpuinfo here, just so I have a record of it?  Perhaps it's vaguely related to the lahf problem (Though that was SIGILL, not SIGSEGV).

You could perhaps try forcing a 32-bit only install (Turn off USE="64bit") and running with nspluginwrapper just to see if that makes it better?
Comment 20 Jim Ramsay (lack) (RETIRED) gentoo-dev 2009-08-22 19:57:37 UTC
Also, please re-test with www-plugins/adobe-flash-10.0.32.18 which is reportedly more stable.
Comment 21 Nico Schlömer 2009-08-22 22:12:22 UTC
Yep, that's the one I'm using; still crashing.

There was some feedback in the meantime of the Adobe bug squad, but it doesn't seem to be a particularly active topic. I sent them the back trace of the segfault, and I'm waiting for more feedback since then.

Btw, the bug report is classified as critical and hence not made public (accessible not even by me).

Cheers,
Nico
Comment 22 Nico Schlömer 2010-01-18 07:49:40 UTC
The new version 10.0.42.34 doesn't seem to have the problem anymore.

Closing as fixed.