[issue8330] Failures seen in test_gdb on buildbots

[Dave Malcolm]

Dave Malcolm <dmalcolm at redhat.com> added the comment:

Both of the failing tests use "set" inside gdb to try to corrupt the memory of the inferior process.

I believe the issue here is that reading through 0xDEADBEEF within gdb on this machine isn't generating a RuntimeError; perhaps that _is_ a valid pointer in the address space of that process (or perhaps we're seeing another gdb-vs-gdb version difference aka issue #8279)

Within PrettyPrintTests.test_corrupt_tp_name, such a situation leads to the use of tp_flags, and the presence of Py_TPFLAGS_INT_SUBCLASS leads to python-gdb.py using PyIntObject, and it correctly print "42", even after op->ob_type->tp_name now has a garbage value, whereas the test was expecting the fallback handler.

Within PrettyPrintTests.test_corrupt_ob_type, it appears that we're using FakeRepr, and that ((PyTypeObject*)0xDEADBEEF->tp_name) within the process pointed at a NUL byte, when my code was expecting gdb to fail to read through ((PyTypeObject*)0xDEADBEEF->tp_name) with a RuntimeError.

I'm attaching a patch which tries to generalize the expected output from these tests, so that they pass if the corruption in the inferior process doesn't manage to confuse gdb, and if 0xDEADBEEF happens to point at something unexpected.

I tested this with PrettyPrintTests active (it continues to all pass on my machine), but commented it out when generating the patch.

This also includes the fix for the DeprecationWarning mentioned in msg102546

----------
Added file: http://bugs.python.org/file16808/fix-overfussy-gdb_text_corruption-tests-and-deprecation-warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8330>
_______________________________________