Bug 639985 - Firefox crashes with xulrunner-python installed
Firefox crashes with xulrunner-python installed
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Malcolm
Fedora Extras Quality Assurance
:
: 649821 651588 (view as bug list)
Depends On:
Blocks: FedoraMini/Mobility SOAS-4
  Show dependency treegraph
 
Reported: 2010-10-04 09:37 EDT by Peter Robinson
Modified: 2012-03-14 07:21 EDT (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-14 07:21:55 EDT
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 Peter Robinson 2010-10-04 09:37:42 EDT
I'm not sure if this is an issue with python, xulrunner or firefox.

On current F-14 on x86_64 platforms firefox crashes if the xulrunner-python package is installed.

This is used by sugar-browse which is the web browser for the sugar learning environment 

$ firefox 
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site.py", line 553, in <module>
    main()
  File "/usr/lib64/python2.7/site.py", line 536, in main
    known_paths = addsitepackages(known_paths)
  File "/usr/lib64/python2.7/site.py", line 315, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib64/python2.7/site.py", line 188, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib64/python2.7/site.py", line 158, in addpackage
    exec line
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/abrt_exception_handler.py", line 28, in <module>
    import subprocess
  File "/usr/lib64/python2.7/subprocess.py", line 428, in <module>
    import select
ImportError: /usr/lib64/python2.7/lib-dynload/selectmodule.so: undefined symbol: _Py_ZeroStruct


This should be reproducible on any 64 bit install with that installed.

xulrunner-1.9.2.10-1.fc14.x86_64
firefox-3.6.10-1.fc14.x86_64
sugar-browse-118-1.fc14
xulrunner-python-1.9.2-4.20100111hg.fc14
Comment 1 Martin Stransky 2010-10-04 09:41:14 EDT
Looks like a bug in xulrunner-python...
Comment 2 Adam Williamson 2010-10-04 16:04:12 EDT
Given that this is only installed by default outside of KDE and GNOME spins and people aren't particularly likely to install it manually or as part of a dep chain for something else, I'd probably vote for this to be NTH since we're considering non-core desktop criteria breakages to be NTH rather than blocker for F14 cycle.
Comment 3 Peter Robinson 2010-10-04 17:06:56 EDT
(In reply to comment #2)
> Given that this is only installed by default outside of KDE and GNOME spins and
> people aren't particularly likely to install it manually or as part of a dep
> chain for something else, I'd probably vote for this to be NTH since we're
> considering non-core desktop criteria breakages to be NTH rather than blocker
> for F14 cycle.

Its a dependency for the sugar browser which is part of Sugar on a Stick, hence my reason for adding it as a blocker.
Comment 4 Adam Williamson 2010-10-04 18:00:20 EDT
I'm going to send out an 'announcement' for this soon, but because the whole status of non-default desktops and the non-desktop spins is hugely unclear, I partly reverted the plan to have issues in desktops beside GNOME and KDE as blockers for F14; for F14 we're treating desktop validation failures in anything but GNOME and KDE as nice-to-have rather than blockers, and we need some input from the Board to decide how we should handle them post-F14.

(This came out of a long discussion between me and Jesse, it's a shame we couldn't do it at FUDCon with you and Christoph too but Jesse only really became aware of the desktop blocker proposal the day after FUDCon and we discussed it via email then. I can forward you the whole thread if you like.)
Comment 5 Martin Stransky 2010-10-05 03:31:17 EDT
Actually it seems to be a problem with python/sugar-browser, see for instance this page:

http://wiki.freeswitch.org/wiki/Mod_python#ImportError:_.2Fusr.2Flib.2F...2Fdatetime.so:_undefinedsymbol:__Py_ZeroStruct
Comment 6 Martin Stransky 2010-10-05 03:35:42 EDT
The missing "ZeroStruct" symbol isn't from xulrunner-python nor sugar-browse packages.
Comment 7 Peter Robinson 2010-10-05 04:45:35 EDT
(In reply to comment #5)
> Actually it seems to be a problem with python/sugar-browser, see for instance
> this page:
> 
> http://wiki.freeswitch.org/wiki/Mod_python#ImportError:_.2Fusr.2Flib.2F...2Fdatetime.so:_undefinedsymbol:__Py_ZeroStruct

In this case I was trying to run firefox not the sugar browser so not sure how that is the problem. xulrunner-python was installed because I also use sugar for testing the environment but I was running a pretty bog standard gnome desktop with firefox.
Comment 8 Martin Stransky 2010-10-05 05:16:58 EDT
I guess it happens when firefox is starting and the python component is initialized.
Comment 9 Paul W. Frields 2010-10-06 16:05:17 EDT
Just a note for people who were unaware -- assignee for this bug (dmalcolm) is on vacation until Monday 2010-10-11.
Comment 10 John Poelstra 2010-10-06 17:29:39 EDT
(In reply to comment #9)
> Just a note for people who were unaware -- assignee for this bug (dmalcolm) is
> on vacation until Monday 2010-10-11.

Is there someone else we can ping for help on this bug?
Comment 11 Paul W. Frields 2010-10-07 09:03:21 EDT
I can't duplicate this bug here on F14 x86_64.

$ rpm -q firefox xulrunner xulrunner-python sugar-browse
firefox-3.6.10-1.fc14.x86_64
xulrunner-1.9.2.10-1.fc14.x86_64
xulrunner-python-1.9.2-4.20100111hg.fc14.x86_64
sugar-browse-118-1.fc14.noarch

Firefox is starting normally.  Peter, can you duplicate this with a new account or fresh install?
Comment 12 Peter Robinson 2010-10-07 13:57:17 EDT
I've duplicated this on two devices. I'm travelling at the moment. I'll try a new profile when I get home tomorrow or over the weekend.
Comment 13 Adam Williamson 2010-10-08 12:37:53 EDT
This was discussed at the 2010-10-08 blocker/nth review meeting. We agreed it doesn't constitute a release blocker as it doesn't seem to affect any default desktop cases, but accepted it as a nice-to-have on the grounds that it constitutes a failure of the desktop validation testing for a non-default spin (SoaS).
Comment 14 Peter Robinson 2010-10-09 13:43:24 EDT
It also happens on my i686 netbook.
Comment 15 Dave Malcolm 2010-10-11 12:10:38 EDT
What version of "python", "python-libs" and "abrt-addon-python" is installed?

The symbol "_Py_ZeroStruct" is the singleton instance of the "False" boolean within libpython; it's provided by this ELF file:
 [david@f14 ~]$ eu-readelf -s /usr/lib64/libpython2.7.so.1.0|grep ZeroStruct
   755: 0000003b521888b0     24 OBJECT  GLOBAL DEFAULT       23 _Py_ZeroStruct

which is within the python-libs subpackage of the python src.rpm:
 [david@f14 ~]$ rpm -qf /usr/lib64/libpython2.7.so.1.0
 python-libs-2.7-8.fc14.1.x86_64

Similarly:
  [david@f14 ~]$ rpm -qf /usr/lib/python2.7/site-packages/abrt_exception_handler.py
  abrt-addon-python-1.1.13-2.fc14.x86_64

I've tested this by starting "firefox" from a gnome-terminal in a gnome session.   I'm not seeing any ImportError with the following combination of packages:
 [david@f14 ~]$ rpm -q python python-libs abrt-addon-python xulrunner xulrunner-python firefox
 python-2.7-8.fc14.1.x86_64
 python-libs-2.7-8.fc14.1.x86_64
 abrt-addon-python-1.1.13-2.fc14.x86_64
 xulrunner-1.9.2.10-1.fc14.1.x86_64
 xulrunner-python-1.9.2-4.20100111hg.fc14.x86_64
 firefox-3.6.10-1.fc14.x86_64

Is there a particular recipe to be followed to reproduce the error (e.g. involving sugar), or do you see this with a gnome firefox startup?

I checked the various libraries within xulrunner-python:
 [david@f14 ~]$ rpm -ql xulrunner-python | grep so
 /usr/lib64/xulrunner-1.9.2/components/libpydom.so
 /usr/lib64/xulrunner-1.9.2/components/libpyloader.so
 /usr/lib64/xulrunner-1.9.2/libpyxpcom.so
 /usr/lib64/xulrunner-1.9.2/python/xpcom/_xpcom.so
and in each case, they have a "NEEDED" requirement on the libpython library, which provides this symbol.  So this ought to work, unless xulrunner-python is doing something unusual in the way it loads dynamic libraries.

If this problem is still being seen, my next thoughts would be: 
(i) to see if sys.get/setdlopenflags() is geing set to something non-standard.  Python uses this when importing modules in the call to "dlopen"; modifying it from the default can break module import.
(ii) to grep through the xulrunner/xulrunner-python sources to find where "dlopen" is called, and see what flags are being passed to it.
Comment 16 Dave Malcolm 2010-10-11 12:16:28 EDT
(In reply to comment #15)
  (snip)
> I checked the various libraries within xulrunner-python:
>  [david@f14 ~]$ rpm -ql xulrunner-python | grep so
>  /usr/lib64/xulrunner-1.9.2/components/libpydom.so
>  /usr/lib64/xulrunner-1.9.2/components/libpyloader.so
>  /usr/lib64/xulrunner-1.9.2/libpyxpcom.so
>  /usr/lib64/xulrunner-1.9.2/python/xpcom/_xpcom.so
> and in each case, they have a "NEEDED" requirement on the libpython library,
> which provides this symbol.  So this ought to work, unless xulrunner-python is
> doing something unusual in the way it loads dynamic libraries.
FWIW, this is via:
 [david@f14 ~]$ eu-readelf -d /usr/lib64/xulrunner-1.9.2/libpyxpcom.so | grep python
  NEEDED            Shared library: [libpython2.7.so.1.0]

  (snip)
Comment 17 Peter Robinson 2010-10-11 12:36:24 EDT
(In reply to comment #15)
> What version of "python", "python-libs" and "abrt-addon-python" is installed?

rpm -q python python-libs abrt-addon-python
python-2.7-8.fc14.1.x86_64
python-libs-2.7-8.fc14.1.x86_64
abrt-addon-python-1.1.13-2.fc14.x86_64

> The symbol "_Py_ZeroStruct" is the singleton instance of the "False" boolean
> within libpython; it's provided by this ELF file:
>  [david@f14 ~]$ eu-readelf -s /usr/lib64/libpython2.7.so.1.0|grep ZeroStruct
>    755: 0000003b521888b0     24 OBJECT  GLOBAL DEFAULT       23 _Py_ZeroStruct
> 
> which is within the python-libs subpackage of the python src.rpm:
>  [david@f14 ~]$ rpm -qf /usr/lib64/libpython2.7.so.1.0
>  python-libs-2.7-8.fc14.1.x86_64

[root@neo ~]#  rpm -qf /usr/lib64/libpython2.7.so.1.0
python-libs-2.7-8.fc14.1.x86_64

> Similarly:
>   [david@f14 ~]$ rpm -qf
> /usr/lib/python2.7/site-packages/abrt_exception_handler.py
>   abrt-addon-python-1.1.13-2.fc14.x86_64
> 
> I've tested this by starting "firefox" from a gnome-terminal in a gnome
> session.   I'm not seeing any ImportError with the following combination of
> packages:
>  [david@f14 ~]$ rpm -q python python-libs abrt-addon-python xulrunner
> xulrunner-python firefox
>  python-2.7-8.fc14.1.x86_64
>  python-libs-2.7-8.fc14.1.x86_64
>  abrt-addon-python-1.1.13-2.fc14.x86_64
>  xulrunner-1.9.2.10-1.fc14.1.x86_64
>  xulrunner-python-1.9.2-4.20100111hg.fc14.x86_64
>  firefox-3.6.10-1.fc14.x86_64
> 
> Is there a particular recipe to be followed to reproduce the error (e.g.
> involving sugar), or do you see this with a gnome firefox startup?

I see it from within gnome when I have the sugar environment installed. So you should be able to do "yum groupinstall sugar-desktop" and get pretty close to what I have installed.

> I checked the various libraries within xulrunner-python:
>  [david@f14 ~]$ rpm -ql xulrunner-python | grep so
>  /usr/lib64/xulrunner-1.9.2/components/libpydom.so
>  /usr/lib64/xulrunner-1.9.2/components/libpyloader.so
>  /usr/lib64/xulrunner-1.9.2/libpyxpcom.so
>  /usr/lib64/xulrunner-1.9.2/python/xpcom/_xpcom.so
> and in each case, they have a "NEEDED" requirement on the libpython library,
> which provides this symbol.  So this ought to work, unless xulrunner-python is
> doing something unusual in the way it loads dynamic libraries.

Well on the two devices I first saw it happen on they were both yum upgraded. But I also have a netbook which was clean installed which on testing saw the same issues. I'll test some more shortly.
Comment 18 Dave Malcolm 2010-10-11 14:35:00 EDT
(In reply to comment #17)
> (In reply to comment #15)
  (snip)
> > Is there a particular recipe to be followed to reproduce the error (e.g.
> > involving sugar), or do you see this with a gnome firefox startup?
> 
> I see it from within gnome when I have the sugar environment installed. So you
> should be able to do "yum groupinstall sugar-desktop" and get pretty close to
> what I have installed.

I've now installed the "sugar-desktop" group.

Running "firefox" from gnome-terminal in a gnome session continues to work fine.

Logged in to a sugar session, clicking on the "Browse" activity (globe symbol) led to a pulsating globe icon in the center of the screen, followed by the sugar session exiting, and X restarting, returning me to the gdm login screen.

However, on logging back in and trying again, it worked, and a browser UI appeared

I haven't been able to reproduce the crash of the sugar session.
Comment 19 Jacek Pliszka 2010-10-13 13:57:12 EDT
My test machine is 32bit, yum upgraded from F13, standard GNOME.

$ eu-readelf -s /usr/lib/libpython2.7.so.1.0  | grep ZeroS
 
756: 0243b804     12 OBJECT  GLOBAL DEFAULT       23 _Py_ZeroStruct

I had 100% reproducability of the error. Then I removed  xulrunner-python-1.9.2-4.20100111hg.fc14.i686 and error disappeared.

Then I tried to install xulrunner-python-1.9.2-4.20100111hg.fc14.i686 again - after installation firefox worked.
Comment 20 Jacek Pliszka 2010-10-13 14:03:16 EDT
Could others confirm this workaround? removing  xulrunner-python  and installing it back again?
Comment 21 Simon Schampijer 2010-10-14 04:12:19 EDT
I have tried to reproduce the error here without luck. Did run as well firefox and the Browse activity in the sugar emulator at the same time.
Comment 22 Adam Williamson 2010-11-01 19:02:42 EDT
Removing F14 NTH status as F14 is now out.

Remaining open nice-to-have issues do NOT automatically become nice-to-have issues for Fedora 15. If you believe a Fedora 14 issue which was accepted as
nice-to-have but not resolved in time for release should also qualify for
nice-to-have status for Fedora 15, please re-propose it as nice-to-have for
Fedora 15.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 23 Dave Malcolm 2010-11-01 19:32:16 EDT
Peter: are you still seeing this?

Is anyone still able to see this bug?
Comment 24 marian.trizuliak 2010-11-03 14:13:13 EDT
Removing xulrunner-python resolved this issue on my machine (Dell E4200, running Fedora 14 x86 upgraded from version 13 via yum).
Comment 25 Sandro Janke 2010-11-06 12:15:12 EDT
I am still seeing this on a netbook where I originally installed F13 LXDE spin then pre-upgraded to F14. Later on I installed "Sugar Desktop Environment" group. I haven't tried re-installing xulrunner-python, yet.

I'll get along using Epiphany at the moment. I'll be glad to assist in tracking this issue down. However, I'll need some guidance.
Comment 26 satellitgo 2010-11-12 03:01:40 EST
https://bugzilla.redhat.com/show_bug.cgi?id=651588

F14 Netinstall
 http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/x86_64/iso/Fedora-14-x86_64-netinst.iso

customize now 

sugar-desktop (including sugar-emulator)
Oracle Virtualbox HD on OSX 10.6.4
MacBook AIR

This defeats the purpose of having a gnome desktop with the education/sugar option available. 
No one is going to accept loss of the browser in gnome ! 
I did a  removal and re installation of firefox which did not fix this problem
Comment 27 John Hall 2010-11-28 03:12:15 EST
I have the same bug under different conditions and I figure knowing them may help solve the bug.
I used preupgrade rather than yum to upgrade from F12 to F14. 
My installation is 32-bit. While i have 64-bit processor I don't have enough RAM on my laptop to make 64 bit worth it.
The error started occuring when running Firefox after installing pyxpcom ( xulrunner-python) for use with Pyjamas not, at least for now, for Sugar. This installation follwed the upgrade.. 
My versions of relevant packages are the same except they are 32-bit and I have this later package: abrt-addon-python-1.1.14-1 .
removing xulrunner and adding it back alone did not solve the problem.
The problem was only solved when firefox was executed while xulrunner-python was not installed. Firefox then runs fine after it's installed with now command line options.
Running firefox with some command line options like -ProfileManger or -help causes the error even after the problem seems 'fixed'..
I found that while other options give errors running my special profile with no extentions works:
firefox -P NoExtentions
This profile runs but was not run after xulrunner-python uninstalled. This profile is not even in the default but is an absolute map in profiles.ini because it's in a folder syncronized from my workstation. Other similarlly configured profiles fail.
I will try to research the issue further and report back any solutions. I am first going to work on a partial hack that willl provide a way to easily make all profiles useable and chooseable either with Profile Manager or a simple script that will allow a choice between profiles defined in profiles.ini. I suspect if we can figure out how the issue may be profile or extension related then I'll be able to trace down the root cause.
Comment 28 Samuel Sieb 2010-11-28 16:47:49 EST
I had this problem.  After reading this bug, I removed xulrunner-python which also removed hulahop and sugar-browse.  Firefox then worked again.  I re-installed sugar-browse (with dependencies) and firefox stopped working.  Removed them all, then re-installed one at a time.  Firefox still works.  Removed them all again and re-installed them all together.  Firefox still works.  Actually, it only appears to work.  As the last poster mentioned, "firefox -help" still shows the problem.
Comment 29 Samuel Sieb 2010-11-28 16:56:23 EST
I found something related to why it still appears to work.  If you remove the compreg.dat file from your profile, firefox will exhibit the problem again.
Comment 30 Samuel Sieb 2010-11-28 17:01:57 EST
I removed the abrt-addon-python package and now firefox doesn't exit and there's a new error:

$ firefox
Obtaining the module object from Python failed.

Traceback (most recent call last):
cant import cStringIO
<type 'exceptions.ImportError'>: /usr/lib/python2.7/lib-dynload/timemodule.so: undefined symbol: PyExc_ValueError

So it appears that it was abrt that was stopping firefox from running when it hit that error.
Comment 31 Samuel Sieb 2010-12-06 22:30:10 EST
This issue was filed against Python and closed as mostly invalid: http://bugs.python.org/issue4434

The answer there is that you have two options. You either have to explicitly load the python shared library in libpyxpcom.so: dlopen("libpython2.7.so.1.0", RTLD_LAZY |RTLD_GLOBAL) or make lib-dynload/*.so explicitly link to libpython2.7.so.1.0.
Comment 32 Samuel Sieb 2010-12-06 22:50:18 EST
In the process of trying to test these options, I needed to install the python-devel package.  When I tested firefox, it suddenly works with no errors.  I removed the python-devel package and again it has the error.  I will see if I can figure out what is in there that solves the problem.
Comment 33 Samuel Sieb 2010-12-06 23:08:57 EST
That turned out to be really easy.  Something is looking for libpython2.7.so.  I created that link to libpython2.7.so.1.0 and there are no more issues.
Comment 34 Cedric Buissart 2010-12-28 17:48:26 EST
workaround from comment 33 worked for me as well. Thanks!
Comment 35 Martin Stransky 2011-01-06 12:26:41 EST
*** Bug 649821 has been marked as a duplicate of this bug. ***
Comment 36 Mike B. 2011-02-17 10:00:59 EST
*** Bug 651588 has been marked as a duplicate of this bug. ***
Comment 37 Danishka Navin 2011-02-18 11:57:50 EST
i have the same issue when i was trying to use gnome and sugar desktops in same system.

Samuel, could you please tell me about creating the link?
Comment 38 Dave Malcolm 2011-02-18 12:00:51 EST
(In reply to comment #37)
> i have the same issue when i was trying to use gnome and sugar desktops in same
> system.
> 
> Samuel, could you please tell me about creating the link?

One easy way to do this is to install the "python-devel" subpackage, which contains such a link.
Comment 39 Jeroen van Meeuwen 2011-02-20 11:10:02 EST
Removing abrt entirely solved this problem for me.
Comment 40 Ryan Spinuzzi 2011-02-27 17:15:30 EST
After running into this same problem I consulted the Fedora irc.  It was suggested that I remove xulrunner-python-1.9.2-4.20100111hg.fc14.x86_64, which also removed hulahop-0.7.1-3.fc14.x86_64, and sugar-browse-120-1.fc14.noarch

I then opened firefox and it everything worked as it should.

*Because I wanted the sugar-browse I reinstalled it (don't ask I have learned that simply reinstalling the app in question sometimes works).  yum installed xulrunner-python-1.9.2-4.20100111hg.fc14.x86_64, and hulahop-0.7.1-3.fc14.x86_64 for it's dependencies.

Being right back in the same position I was before you would think that firefox would crash again.  It did not.  Everything worked just fine, including firefox, and sugar browse.

Jeroen van Meeuwen suggested removing abrt entirely.  I have the following abrt packages installed:

abrt.x86_64, abrt-addon-ccpp.x86_64, abrt-addon-kerneloops.x86_64, abrt-addon-python.x86_64, abrt-cli.x86_64, abrt-desktop.x86_64, abrt-gui.x86_64, abrt-libs.x86_64, abrt-plugin-bugzilla.x86_64, abrt-plugin-filetransfer.x86_64, abrt-plugin-logger.x86_64, abrt-plugin-mailx.x86_64, abrt-plugin-reportuploader.x86_64, abrt-plugin-rhtsupport.x86_64, abrt-plugin-runapp.x86_64, abrt-plugin-sosreport.x86_64

I never touched the removal or abrt or any of it's components.  I only did what I listed above *.  That worked just fine for me.  I am not going to say that this method will work for you as well, but I wanted to post what worked for me.

I have tested this on a i686, and x64 system.

I take absolutely no responsibility if your system brakes per my advice.
Comment 41 Samuel Sieb 2011-02-27 22:06:48 EST
Ryan, please see comment #28 and #29 for the explanation of why it appears to work.

The question is still why xulrunner-python or a dependency is linking directly to libpython2.7.so instead of the properly versioned one.
Comment 42 Frantisek Hanzlik 2011-06-09 10:59:20 EDT
Fresh F14 i686 install (with updates upto now), sugar installed.
FF immediately on start crashes:
$ firefox
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 549, in <module>
    main()
  File "/usr/lib/python2.7/site.py", line 532, in main
    known_paths = addsitepackages(known_paths)
  File "/usr/lib/python2.7/site.py", line 311, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib/python2.7/site.py", line 188, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib/python2.7/site.py", line 158, in addpackage
    exec line
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/abrt_exception_handler.py", line 28, in <module>
    import subprocess
  File "/usr/lib/python2.7/subprocess.py", line 428, in <module>
    import select
ImportError: /usr/lib/python2.7/lib-dynload/selectmodule.so: undefined symbol: _Py_ZeroStruct

Component versions:
# rpm -q python python-libs abrt-addon-python xulrunner xulrunner-python firefox
python-2.7-8.fc14.1.i686
python-libs-2.7-8.fc14.1.i686
abrt-addon-python-1.1.18-1.fc14.i686
xulrunner-1.9.2.17-2.fc14.i686
xulrunner-python-1.9.2-4.20100111hg.fc14.i686
firefox-3.6.17-1.fc14.i686

After uninstalling xulrunner-python, FF is running fine.
When then installing xulrunner-python-1.9.2-4.20100111hg.fc14.i686 again, FF now starting fine without crashes.
Comment 43 Peter Robinson 2012-03-14 07:21:55 EDT
long seems to be fixed.

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