[PATCH] [gdb/python] Issue warning if python fails to initialize

[PATCH] [gdb/python] Issue warning if python fails to initialize

[Tom de Vries]

A common problem is that python may fail to initialize if PYTHONHOME is
set incorrectly, or points to an incompatible python installation.

For instance, say PYTHONHOME is foo, then we get:
...
$ gdb -q
Python path configuration:
  PYTHONHOME = 'foo'
  PYTHONPATH = (not set)
  program name = '/usr/bin/python'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = 'foo/lib64/python3.12'
  sys._base_executable = '/usr/bin/python'
  sys.base_prefix = 'foo'
  sys.base_exec_prefix = 'foo'
  sys.platlibdir = 'lib64'
  sys.executable = '/usr/bin/python'
  sys.prefix = 'foo'
  sys.exec_prefix = 'foo'
  sys.path = [
    'foo/lib64/python312.zip',
    'foo/lib64/python3.12',
    'foo/lib64/python3.12/lib-dynload',
  ]
Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
Python not initialized
$
...

In this case, it might be easy to figure out what went wrong because of the
obviously incorrect pathnames, but that might not be the case if PYTHONHOME
points to an incompatible python installation.

Fix this by adding a warning with a description of the possible cause and what
to do about it:
...
Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
gdb: warning: Python failed to initialize: Maybe because PYTHONHOME is set \
  incorrectly, or points to an incompatible installation?  Consider changing \
  or unsetting PYTHONHOME, or ignoring it using "set python \
  ignore-environment on"
Python not initialized
$
...

Tested on aarch64-linux.
---
 gdb/python/python.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/gdb/python/python.c b/gdb/python/python.c
index 397431a4c84..ab90ead7dca 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -2717,8 +2717,20 @@ do_initialize (const struct extension_language_defn *extlang)
 static void
 gdbpy_initialize (const struct extension_language_defn *extlang)
 {
-  if (!do_start_initialization () && PyErr_Occurred ())
-    gdbpy_print_stack ();
+  if (!do_start_initialization ())
+    {
+      if (PyErr_Occurred ())
+	gdbpy_print_stack ();
+
+      if (!Py_IsInitialized ()
+	  && !python_ignore_environment
+	  && getenv ("PYTHONHOME") != nullptr)
+	warning (_("Python failed to initialize: Maybe because PYTHONHOME is"
+		   " set incorrectly, or points to an incompatible"
+		   " installation?  Consider changing or unsetting"
+		   " PYTHONHOME, or ignoring it using \"set python"
+		   " ignore-environment on\""));
+    }
 
   gdbpy_enter enter_py;
 

base-commit: be740e7cc62fed098ad62cef3b2e2b25b44d8748
-- 
2.35.3

Re: [PATCH] [gdb/python] Issue warning if python fails to initialize

[Andrew Burgess]

Tom de Vries <tdevries@suse.de> writes:

> A common problem is that python may fail to initialize if PYTHONHOME is
> set incorrectly, or points to an incompatible python installation.
>
> For instance, say PYTHONHOME is foo, then we get:
> ...
> $ gdb -q
> Python path configuration:
>   PYTHONHOME = 'foo'
>   PYTHONPATH = (not set)
>   program name = '/usr/bin/python'
>   isolated = 0
>   environment = 1
>   user site = 1
>   safe_path = 0
>   import site = 1
>   is in build tree = 0
>   stdlib dir = 'foo/lib64/python3.12'
>   sys._base_executable = '/usr/bin/python'
>   sys.base_prefix = 'foo'
>   sys.base_exec_prefix = 'foo'
>   sys.platlibdir = 'lib64'
>   sys.executable = '/usr/bin/python'
>   sys.prefix = 'foo'
>   sys.exec_prefix = 'foo'
>   sys.path = [
>     'foo/lib64/python312.zip',
>     'foo/lib64/python3.12',
>     'foo/lib64/python3.12/lib-dynload',
>   ]
> Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
> Python not initialized
> $
> ...
>
> In this case, it might be easy to figure out what went wrong because of the
> obviously incorrect pathnames, but that might not be the case if PYTHONHOME
> points to an incompatible python installation.
>
> Fix this by adding a warning with a description of the possible cause and what
> to do about it:
> ...
> Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
> gdb: warning: Python failed to initialize: Maybe because PYTHONHOME is set \
>   incorrectly, or points to an incompatible installation?  Consider changing \
>   or unsetting PYTHONHOME, or ignoring it using "set python \
>   ignore-environment on"
> Python not initialized
> $
> ...
>
> Tested on aarch64-linux.
> ---
>  gdb/python/python.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/python/python.c b/gdb/python/python.c
> index 397431a4c84..ab90ead7dca 100644
> --- a/gdb/python/python.c
> +++ b/gdb/python/python.c
> @@ -2717,8 +2717,20 @@ do_initialize (const struct extension_language_defn *extlang)
>  static void
>  gdbpy_initialize (const struct extension_language_defn *extlang)
>  {
> -  if (!do_start_initialization () && PyErr_Occurred ())
> -    gdbpy_print_stack ();
> +  if (!do_start_initialization ())
> +    {
> +      if (PyErr_Occurred ())
> +	gdbpy_print_stack ();
> +
> +      if (!Py_IsInitialized ()
> +	  && !python_ignore_environment
> +	  && getenv ("PYTHONHOME") != nullptr)
> +	warning (_("Python failed to initialize: Maybe because PYTHONHOME is"
> +		   " set incorrectly, or points to an incompatible"
> +		   " installation?  Consider changing or unsetting"
> +		   " PYTHONHOME, or ignoring it using \"set python"
> +		   " ignore-environment on\""));

This looks good.  I wonder if we should be checking (and mentioning)
PYTHONPATH too?  I'm no Python (environment) expert, so I'm not sure if
this is sensible or not.

Thanks,
Andrew

> +    }
>  
>    gdbpy_enter enter_py;
>  
>
> base-commit: be740e7cc62fed098ad62cef3b2e2b25b44d8748
> -- 
> 2.35.3

Re: [PATCH] [gdb/python] Issue warning if python fails to initialize

[Tom de Vries]

On 11/21/24 16:42, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
> 
>> A common problem is that python may fail to initialize if PYTHONHOME is
>> set incorrectly, or points to an incompatible python installation.
>>
>> For instance, say PYTHONHOME is foo, then we get:
>> ...
>> $ gdb -q
>> Python path configuration:
>>    PYTHONHOME = 'foo'
>>    PYTHONPATH = (not set)
>>    program name = '/usr/bin/python'
>>    isolated = 0
>>    environment = 1
>>    user site = 1
>>    safe_path = 0
>>    import site = 1
>>    is in build tree = 0
>>    stdlib dir = 'foo/lib64/python3.12'
>>    sys._base_executable = '/usr/bin/python'
>>    sys.base_prefix = 'foo'
>>    sys.base_exec_prefix = 'foo'
>>    sys.platlibdir = 'lib64'
>>    sys.executable = '/usr/bin/python'
>>    sys.prefix = 'foo'
>>    sys.exec_prefix = 'foo'
>>    sys.path = [
>>      'foo/lib64/python312.zip',
>>      'foo/lib64/python3.12',
>>      'foo/lib64/python3.12/lib-dynload',
>>    ]
>> Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
>> Python not initialized
>> $
>> ...
>>
>> In this case, it might be easy to figure out what went wrong because of the
>> obviously incorrect pathnames, but that might not be the case if PYTHONHOME
>> points to an incompatible python installation.
>>
>> Fix this by adding a warning with a description of the possible cause and what
>> to do about it:
>> ...
>> Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
>> gdb: warning: Python failed to initialize: Maybe because PYTHONHOME is set \
>>    incorrectly, or points to an incompatible installation?  Consider changing \
>>    or unsetting PYTHONHOME, or ignoring it using "set python \
>>    ignore-environment on"
>> Python not initialized
>> $
>> ...
>>
>> Tested on aarch64-linux.
>> ---
>>   gdb/python/python.c | 16 ++++++++++++++--
>>   1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdb/python/python.c b/gdb/python/python.c
>> index 397431a4c84..ab90ead7dca 100644
>> --- a/gdb/python/python.c
>> +++ b/gdb/python/python.c
>> @@ -2717,8 +2717,20 @@ do_initialize (const struct extension_language_defn *extlang)
>>   static void
>>   gdbpy_initialize (const struct extension_language_defn *extlang)
>>   {
>> -  if (!do_start_initialization () && PyErr_Occurred ())
>> -    gdbpy_print_stack ();
>> +  if (!do_start_initialization ())
>> +    {
>> +      if (PyErr_Occurred ())
>> +	gdbpy_print_stack ();
>> +
>> +      if (!Py_IsInitialized ()
>> +	  && !python_ignore_environment
>> +	  && getenv ("PYTHONHOME") != nullptr)
>> +	warning (_("Python failed to initialize: Maybe because PYTHONHOME is"
>> +		   " set incorrectly, or points to an incompatible"
>> +		   " installation?  Consider changing or unsetting"
>> +		   " PYTHONHOME, or ignoring it using \"set python"
>> +		   " ignore-environment on\""));
> 
> This looks good.  I wonder if we should be checking (and mentioning)
> PYTHONPATH too?  I'm no Python (environment) expert, so I'm not sure if
> this is sensible or not.
> 

Hi Andrew,

thanks for the review.

After trying a while, I managed to trigger this path also using 
PYTHONPATH, using a 2.7 directory with gdb built against python 3.12. 
So, it's less easy to trigger, but possible.

I've submitted a v2 that adds PYTHONPATH to the warning ( 
https://sourceware.org/pipermail/gdb-patches/2024-November/213491.html ).

Thanks,
- Tom

> Thanks,
> Andrew
> 
>> +    }
>>   
>>     gdbpy_enter enter_py;
>>   
>>
>> base-commit: be740e7cc62fed098ad62cef3b2e2b25b44d8748
>> -- 
>> 2.35.3
>