[Bug python/31425] New: [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[Bug python/31425] New: [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

            Bug ID: 31425
           Summary: [gdb/python, 3.12] FAIL: gdb.python/py-block.exp:
                    check nonexistent variable
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On aarch64-linux, with python 3.12.

Before commit a207f6b3a38 ("Rewrite "python" command exception handling"), we
had:
...
(gdb) python print (block['nonexistent'])^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
KeyError: 'nonexistent'^M
Error while executing Python code.^M
(gdb) PASS: gdb.python/py-block.exp: check nonexistent variable
...
but now we have:
...
(gdb) python print (block['nonexistent'])^M
Python Exception <class 'KeyError'>: 'nonexistent'^M
Error occurred in Python: 'nonexistent'^M
(gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable
...

The change in the test-case is:
...
-gdb_test "python print (block\['nonexistent'\])" ".*KeyError: 'nonexistent'.*"
\
+gdb_test "python print (block\['nonexistent'\])" ".*KeyError.*: nonexistent.*"
\
          "check nonexistent variable"
...
which drops the single quotes around the nonexistent string.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
In contrast, on x86_64-linux, with python 3.6.

Before the commit we have:
...
(gdb) python print (block['nonexistent'])^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
KeyError: 'nonexistent'^M
(gdb) PASS: gdb.python/py-block.exp: check nonexistent variable
...
and after the commit:
...
(gdb) python print (block['nonexistent'])^M
Python Exception <class 'KeyError'>: nonexistent^M
Error occurred in Python: nonexistent^M
(gdb) PASS: gdb.python/py-block.exp: check nonexistent variable
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> In contrast, on x86_64-linux, with python 3.6.

Likewise with python 3.11.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
With python 3.6, the value that is set using PyErr_SetObject:
...
(gdb) p PyObject_Print(value, stderr, 0)
'nonexistent'$1 = 0
(gdb) p PyObject_Print(value, stderr, 1)
nonexistent$2 = 0
...
is the same as is fetch using PyErr_Fetch:
...
(gdb) p PyObject_Print(error_value, stderr, 0)
'nonexistent'$3 = 0
(gdb) p PyObject_Print(error_value, stderr, 1)
nonexistent$4 = 0
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> With python 3.6, the value that is set using PyErr_SetObject:
> ...
> (gdb) p PyObject_Print(value, stderr, 0)
> 'nonexistent'$1 = 0
> (gdb) p PyObject_Print(value, stderr, 1)
> nonexistent$2 = 0
> ...
> is the same as is fetch using PyErr_Fetch:
> ...
> (gdb) p PyObject_Print(error_value, stderr, 0)
> 'nonexistent'$3 = 0
> (gdb) p PyObject_Print(error_value, stderr, 1)
> nonexistent$4 = 0
> ...

With python 3.12, we have the same value set using PyErr_SetObject:
...
(gdb) p (int)PyObject_Print(key,stderr, 0)
'nonexistent'$1 = 0
(gdb) p (int)PyObject_Print(key,stderr, 1)
nonexistent$2 = 0
...
but fetch a different value using PyErr_Fetch:
...
gdb) p (int)PyObject_Print(error_value,stderr, 0)
KeyError('nonexistent')$3 = 0
(gdb) p (int)PyObject_Print(error_value,stderr, 1)
'nonexistent'$4 = 0
...

PyErr_Fetch has been deprecated in python 3.12, I wonder if that is relevant
somehow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
The following patch avoid the deprecated PyErr_Fetch for python >= 3.12, and
makes the FAIL disappear:
...
diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index c68aff5340e..3318f8b8c35 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -640,12 +640,31 @@ class gdbpy_err_fetch

   gdbpy_err_fetch ()
   {
+#if PY_VERSION_HEX < 0x030c0000
     PyObject *error_type, *error_value, *error_traceback;

     PyErr_Fetch (&error_type, &error_value, &error_traceback);
     m_error_type.reset (error_type);
     m_error_value.reset (error_value);
     m_error_traceback.reset (error_traceback);
+#else
+    PyObject *ex = PyErr_GetRaisedException ();
+    if (ex == nullptr)
+      {
+       m_error_type.reset (nullptr);
+       m_error_value.reset (nullptr);
+       m_error_traceback.reset (nullptr);
+      }
+    else
+      {
+       m_error_traceback.reset (PyException_GetTraceback (ex));
+       m_error_type.reset ((PyObject *)Py_TYPE (ex));
+       Py_INCREF (m_error_type.get ());
+       PyObject *args = PyException_GetArgs (ex);
+       m_error_value.reset (PyTuple_GetItem (args, 0));
+       Py_INCREF (m_error_value.get ());
+      }
+#endif
   }

   /* Call PyErr_Restore using the values stashed in this object.
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
+       m_error_value.reset (PyTuple_GetItem (args, 0));
+       Py_INCREF (m_error_value.get ());

This kind of thing should be written

m_error_value = gdbpy_ref<>::new_reference (PyTuple_GetItem (...));

i.e., avoiding explicit increfs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Alternatively, this works as well:
...
diff --git a/gdb/python/py-utils.c b/gdb/python/py-utils.c
index 9382eb62a5f..50f070ba380 100644
--- a/gdb/python/py-utils.c
+++ b/gdb/python/py-utils.c
@@ -196,7 +196,15 @@ gdbpy_err_fetch::to_string () const
      gdb.GdbError ("message").  */

   if (m_error_value.get () != nullptr && m_error_value.get () != Py_None)
-    return gdbpy_obj_to_string (m_error_value.get ());
+    {
+      if ((PyObject *)Py_TYPE (m_error_value.get ()) == m_error_type.get ())
+       {
+         PyObject *args = PyException_GetArgs (m_error_value.get ());
+         if (PyTuple_Size (args) == 1)
+           return gdbpy_obj_to_string (PyTuple_GetItem (args, 0));
+       }
+      return gdbpy_obj_to_string (m_error_value.get ());
+    }
   else
     return gdbpy_obj_to_string (m_error_type.get ());
 }
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
I ended up submitting both fixes in a series (
https://sourceware.org/pipermail/gdb-patches/2024-March/207003.html ).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/31425] [gdb/python, 3.12] FAIL: gdb.python/py-block.exp: check nonexistent variable

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31425

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed by:
...
commit 50ede76876981364d6b1a314bb79c0412980c435
Author: Tom de Vries <tdevries@suse.de>
Date:   Sat Mar 9 16:13:10 2024 +0100

    [gdb/python] Normalize exceptions in gdbpy_err_fetch
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.