GNOME Bugzilla – Bug 528953
glChess and Sudoku crash on startup when the python version is not the same as that of build time
Last modified: 2008-10-11 18:06:58 UTC
The following code is completely useless, and makes glchess crash on startup when the python version at runtime is different from the python version at build time. if "#pyexecdir#" not in sys.path: sys.path.insert(0, "#pyexecdir#") See http://bugs.debian.org/476877 for an example of what happens when you do such horrible things.
Created attachment 109645 [details] [review] fix sys.path from Debian by Joss
For background info, see bug #382057.
This is a good thing to have when the python modules are installed in a private directory (e.g. /usr/share/games/glchess). But when they are installed in the public modules directory, like the current makefiles do, it can only make things turn wrong.
I still can't see why this should be causing a problem: - If Gnome Games is compiled to install a directory that is in your sys.path then sys.path is not modified - If the .py files are not in the directory Gnome Games was compiled with Python will first in the compiled directory and then look in the system configured paths (we only prepend this path, not remove any of the system paths).
This is causing a crash when the python version at runtime is different from the python version at build time. In the case of the reported crashes, gnome-games was built with python 2.4, and hardcoded /usr/lib/python2.4/site-packages in the script. After the python upgrade, the python version was 2.5, and adding /usr/lib/python2.4/site-packages to the sys.path immediately causes crashes because some random modules built for 2.4 are loaded by python2.5.
I think the patch in comment #1 will have problems, when glChess is installed in a different prefix than default. Also, GNOME Sudoku will have to be modified in the same way as glChess, because these two games have the same initialization code. Generally, I agree with comment #4...
What exactly isn't clear in "this is causing a crash" ? (BTW, thanks for the gnome-sudoku hint, I'll patch it as well.)
It seems to me that we need an improved fix which handles both: - Installation to a different prefix than the default. - Doesn't crash when upgrading Python. Unforunately very few projects use automake/autoconf for distributing Python code, but it would be interesting to see how other projects in the same situation solve this. Why does Python "immediately crash because some random modules built for 2.4 are loaded by python2.5"? Eg. why are "some random" modules loaded in the first place?
(In reply to comment #8) > Unforunately very few projects use automake/autoconf for distributing Python > code, but it would be interesting to see how other projects in the same > situation solve this. Most projects I know - regardless of the build system - choose between one of the following: * Install modules in the default python path and let the system deal with them and make them available. * Install modules in a fixed, private directory and unconditionally add this directory to sys.path. These two approaches have radically different philosophies - the former makes modules available to other programs, the latter is less prone to namespace conflicts - and trying to support both is going to be unnecessarily complex, with a benefit that I don't grasp. > Why does Python "immediately crash because some random modules built for 2.4 > are loaded by python2.5"? Eg. why are "some random" modules loaded in the first > place? Because when later, the game imports a module, like gtk or cairo, it is found in the python2.4 directory which has been added to sys.path.
> Install modules in the default python path and let the system deal with them and make them available. Let's say we took this approach. glChess would then be installed in /usr/lib/python2.4/site-packages. When upgrading from Python 2.4 to 2.5, Python would look and not find glChess in the new python library path /usr/lib/python2.5/site-packages. So you would still have problem with this approach, when upgrading Python. If glChess would be installed in the default python path, changes to the makefiles are required, which are not implemented in the patch in comment #1. So if glChess would be installed in a non-default prefix, it wouldn't work because the libraries wouldn't be found by Python without adding it to sys.path.
(In reply to comment #10) > Let's say we took this approach. glChess would then be installed in > /usr/lib/python2.4/site-packages. When upgrading from Python 2.4 to 2.5, Python > would look and not find glChess in the new python library path > /usr/lib/python2.5/site-packages. So you would still have problem with this > approach, when upgrading Python. No, because we make these modules available automatically for all supported python versions. Therefore, they already appear in /var/lib/python-support/python2.5, even when they were built against python2.4. > If glChess would be installed in the default python path, changes to the > makefiles are required, which are not implemented in the patch in comment #1. > So if glChess would be installed in a non-default prefix, it wouldn't work > because the libraries wouldn't be found by Python without adding it to > sys.path. Installing public python modules in a non-default prefix will not work without fiddling with PYTHONPATH or modifying site.py, anyway. That is expected. Just like installing binaries in a non-default prefix will not work without fiddling with PATH.
> No, because we make these modules available automatically for all supported > python versions. Therefore, they already appear in > /var/lib/python-support/python2.5, even when they were built against python2.4. How?
*** Bug 528234 has been marked as a duplicate of this bug. ***
Bug 528234 and all the duplicates are showing these symptons, i.e: Running glChess using Python 2.5 but opening the cairo object file from the Python 2.4 directory. Due to the number of problems I recommend applying the patch as given for 2.22.2 and solve the non-standard installation path at another time. Perhaps we need a new configure flag to include the path only if requested.
*** Bug 528471 has been marked as a duplicate of this bug. ***
*** Bug 528561 has been marked as a duplicate of this bug. ***
*** Bug 528569 has been marked as a duplicate of this bug. ***
*** Bug 528739 has been marked as a duplicate of this bug. ***
*** Bug 531793 has been marked as a duplicate of this bug. ***
*** Bug 531829 has been marked as a duplicate of this bug. ***
*** Bug 531891 has been marked as a duplicate of this bug. ***
*** Bug 531991 has been marked as a duplicate of this bug. ***
*** Bug 532024 has been marked as a duplicate of this bug. ***
*** Bug 532107 has been marked as a duplicate of this bug. ***
*** Bug 532257 has been marked as a duplicate of this bug. ***
*** Bug 532245 has been marked as a duplicate of this bug. ***
*** Bug 532372 has been marked as a duplicate of this bug. ***
*** Bug 532449 has been marked as a duplicate of this bug. ***
*** Bug 532494 has been marked as a duplicate of this bug. ***
*** Bug 532503 has been marked as a duplicate of this bug. ***
*** Bug 532514 has been marked as a duplicate of this bug. ***
*** Bug 532548 has been marked as a duplicate of this bug. ***
*** Bug 532590 has been marked as a duplicate of this bug. ***
*** Bug 532684 has been marked as a duplicate of this bug. ***
As a reply to comment #14: yes, it seems that the patch can be applied for now, since there are quite a few duplicates of this bug.
*** Bug 532833 has been marked as a duplicate of this bug. ***
*** Bug 532890 has been marked as a duplicate of this bug. ***
*** Bug 532881 has been marked as a duplicate of this bug. ***
Clarifying the case in which this happens: Gnome Games is compiled to install .py files into /usr/lib/python2.4/site-packages. This causes '/usr/lib/python2.4/site-packages' to be prepended (if it is not present) into the path when glChess is run. When glchess is executed on a Python 2.4 system the path is set to ['/usr/lib/python2.4/site-packages']. The path is not modified and the glchess libraries are correctly loaded from '/usr/lib/python2.4/site-packages' when /usr/bin/games/glchess shell script is executed. The user upgrades to Python 2.5 and executes glChess again. The default Python path for the new Python interpreter is ['/usr/lib/python2.5/site-packages'] so '/usr/lib/python2.4/site-packages' is prepended. The python files are loaded from the 2.4 directory and executed using the 2.5 interpreter. Any 2.4 .so packages that are not binary compatible with Python 2.5 throw exceptions. If our top level file had specified the same version of Python as the sys.path then this problem would not have occurred (i.e. the /usr/games/glchess script started with !#/usr/bin/python2.4) but we would have only worked in one version of Python.
Re-assigning to general as it affects both glChess and Sudoku
*** Bug 532997 has been marked as a duplicate of this bug. ***
*** Bug 533067 has been marked as a duplicate of this bug. ***
Fixed in 2.22 and head http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7657 http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7658 http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7659 http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7660
Using Debian testing and made upgrade today, and with the new version the bug is fixed. THX, love GNOME =)
*** Bug 533228 has been marked as a duplicate of this bug. ***
*** Bug 534755 has been marked as a duplicate of this bug. ***
*** Bug 533958 has been marked as a duplicate of this bug. ***
*** Bug 538277 has been marked as a duplicate of this bug. ***
*** Bug 541655 has been marked as a duplicate of this bug. ***
*** Bug 542497 has been marked as a duplicate of this bug. ***
*** Bug 552058 has been marked as a duplicate of this bug. ***
*** Bug 552057 has been marked as a duplicate of this bug. ***
*** Bug 555922 has been marked as a duplicate of this bug. ***