classification
Title: sys.executable is a false path if python is executed from gdb
Type: Stage: resolved
Components: Versions:
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: Volker Weißmann, ammar2, terry.reedy
Priority: normal Keywords:

Created on 2020-04-07 20:16 by Volker Weißmann, last changed 2020-04-12 20:56 by Volker Weißmann. This issue is now closed.

Messages (6)
msg365934 - (view) Author: Volker Weißmann (Volker Weißmann) * Date: 2020-04-07 20:16
Note: I'm not sure if this is a bug in python or in gdb. I will also submit a bug report to gdb and post a link here.

Pythons documentation says that sys.executable is always either None, empty string or a path to the python interpreter. Using gdb and python, we can produce situations where this is not true.

Simple but unrealistic way to reproduce this bug:
Install gdb with python support. E.g using
$ pacman -S gdb
Remove all the python binaries:
$ rm /usr/bin/python
$ rm /usr/bin/python3
$ rm /usr/bin/python3.8
Run $gdb -x gdbinit$ with the contents of gdbinit being:
python
import sys
import os
print(sys.executable)
print(os.path.exists(sys.executable))
end

Result:
/usr/bin/python
False

Here, sys.executable is /usr/bin/python, but there is no python executable in /usr/bin/python, because we just deleted it.

Complicated but realistic way to reproduce this bug:
Build gdb with
../configure --with-python=python2
and run gdb with the gdbinit being:
python
import sys
print(sys.executable)
print(sys.version)
end
Result:
/usr/bin/python
2.7.17 (default, Mar 21 2020, 00:47:07) 
[GCC 9.3.0]
Here it says that the python2 executable lies in "/usr/bin/python", even if there is no python2 executable in /usr/bin/python.
msg365935 - (view) Author: Volker Weißmann (Volker Weißmann) * Date: 2020-04-07 20:20
The gdb issue is here: https://sourceware.org/bugzilla/show_bug.cgi?id=25800
msg366183 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-04-11 02:37
I shortened the title so that 'gdb' shows.  I have never used gdb, but I am curious what *is* the path to the python running the python code after 'python'?  Is it part of or included with gdb?  If so, this seems a gdb bug, as it is the responsibility of the running python to correctly locate itself.  We are only responsible for the binaries we provide (Windows and macOS) or binaries compiled from the unpatched codebase.  (I said 'seems' because it could be that gdb compiles with an untested combination of supported compile switches.)
msg366206 - (view) Author: Volker Weißmann (Volker Weißmann) * Date: 2020-04-11 12:09
"I have never used gdb, but I am curious what *is* the path to the python running the python code after 'python'? Is it part of or included with gdb?"
I honestly don't know. I think the python interpreter gets compiled into the python binary, because as a test, I removed every python interpreter on my system that I could find and the "python" command inside gdb still worked. But it uses some of pythons shared libraries that get installed when you install python.

I also suspect that it is a bug in gdb.
I think the only thing you can do is take a look at python's source code on how it finds sys.executable and check if it looks fishy or if it looks like it should never point to a non existing file. And we can wait if the gdb programmers will respond.
msg366223 - (view) Author: Ammar Askar (ammar2) * (Python committer) Date: 2020-04-11 23:45
The reason you're seeing gdb still work even when all Pythons are deleted is because it embeds a Python interpreter in itself (https://docs.python.org/3/extending/embedding.html).

This issue is thus out of scope here and belongs on the gdb tracker, but I can tell you it's caused by these lines: https://github.com/bminor/binutils-gdb/blob/de7ac122a7f98c181c1ec175b0560bb48eabc6ea/gdb/python/python.c#L1668-L1694

The Py_SetProgramName() is what informs the sys.executable value.
msg366268 - (view) Author: Volker Weißmann (Volker Weißmann) * Date: 2020-04-12 20:56
Ok, thank you. I hope that the gdb guys will respon
History
Date User Action Args
2020-04-12 20:56:37Volker Weißmannsetmessages: + msg366268
2020-04-11 23:50:38terry.reedysetstatus: open -> closed
resolution: third party
stage: resolved
2020-04-11 23:45:36ammar2setnosy: + ammar2
messages: + msg366223
2020-04-11 12:09:38Volker Weißmannsetmessages: + msg366206
2020-04-11 02:37:01terry.reedysetnosy: + terry.reedy

messages: + msg366183
title: sys.executable is a non existing path if python is executed from gdb -> sys.executable is a false path if python is executed from gdb
2020-04-07 20:20:42Volker Weißmannsetmessages: + msg365935
2020-04-07 20:16:39Volker Weißmanncreate