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
Looks like a bug in xulrunner-python...
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.
(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.
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.)
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
The missing "ZeroStruct" symbol isn't from xulrunner-python nor sugar-browse packages.
(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.
I guess it happens when firefox is starting and the python component is initialized.
Just a note for people who were unaware -- assignee for this bug (dmalcolm) is on vacation until Monday 2010-10-11.
(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?
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?
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.
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).
It also happens on my i686 netbook.
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.
(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)
(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.
(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.
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.
Could others confirm this workaround? removing xulrunner-python and installing it back again?
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.
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
Peter: are you still seeing this? Is anyone still able to see this bug?
Removing xulrunner-python resolved this issue on my machine (Dell E4200, running Fedora 14 x86 upgraded from version 13 via yum).
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.
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
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.
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.
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.
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.
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.
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.
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.
workaround from comment 33 worked for me as well. Thanks!
*** Bug 649821 has been marked as a duplicate of this bug. ***
*** Bug 651588 has been marked as a duplicate of this bug. ***
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?
(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.
Removing abrt entirely solved this problem for me.
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.
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.
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.
long seems to be fixed.