sagemath / cysignals

cysignals: interrupt and signal handling for Cython. Source repository for https://pypi.org/project/cysignals/
GNU Lesser General Public License v3.0
43 stars 23 forks source link

Remove mucking with environment variables #58

Closed vbraun closed 7 years ago

vbraun commented 7 years ago

Do not change:

jdemeyer commented 7 years ago

On my system, this makes things worse unfortunately...

Within Sage, I get

Traceback (most recent call last):
  File "<string>", line 26, in <module>
  File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/Cython/Debugger/libpython.py", line 61, in <module>
    import tempfile
  File "/usr/local/src/sage-config/local/lib64/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/usr/local/src/sage-config/local/lib64/python2.7/io.py", line 51, in <module>
    import _io
ImportError: /usr/local/src/sage-config/local/lib64/python2.7/lib-dynload/_io.so: undefined symbol: _PyErr_ReplaceException
Error while executing Python code.

It seems that the system Python is used, together with the runtime files from Sage, resulting in a conflict.

vbraun commented 7 years ago

Is that with a self-compiled gdb, or how else does gdb end up with references to /usr/local/src/sage-config? There are a number of other issues with the Sage gdb package, e.g. it just doesn't work at all on OSX....

jdemeyer commented 7 years ago

Is that with a self-compiled gdb

No, it's my system gdb.

how else does gdb end up with references to /usr/local/src/sage-config?

I don't know really. I guess that Python somehow searches for its own runtime files and finds the one of Sage before the system ones.

vbraun commented 7 years ago

It seems that there are only two ways this could go wrong, either gdb links to the wrong libpython:

$ ldd $(which gdb) | grep python
    libpython3.5m.so.1.0 => /lib64/libpython3.5m.so.1.0 (0x00007ff4b88c5000)

or sys.path is wrong inside the embedded python interpreter:

$ gdb
(gdb) python import sys; print(sys.path);
['/usr/share/gdb/python', '/usr/lib64/python35.zip', '/usr/lib64/python3.5', '/usr/lib64/python3.5/plat-linux', '/usr/lib64/python3.5/lib-dynload', '/usr/lib64/python3.5/site-packages', '/usr/lib/python3.5/site-packages']
(gdb) python import Cython; print(Cython.__file__)
/usr/lib64/python3.5/site-packages/Cython/__init__.py

Though both work for me; The Cython backtrace fails because Python 2<->3 incompatibility but thats to be expected.

vbraun commented 7 years ago

PS: File "", line 26, in refers to cysignals-CSI-helper.py lines, so it seems your gdb dies when running

(gdb) python from Cython.Debugger import libpython, libcython
jdemeyer commented 7 years ago

Got it.

This problem is the python in argv[0] here:

        # Run gdb but pretending to be Python in argv[0].
        # This is needed for Python to find its own files.
        cmd = Popen(["python"], executable=whichgdb,
                stdin=PIPE, stdout=PIPE, stderr=PIPE, env=env)

Replacing python with gdb fixes the problem.

vbraun commented 7 years ago

Ah good catch, thanks!