diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-03-09 10:58:54 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-03-30 10:25:46 +0100 |
commit | 44d9b0a174b08f283001f01aaf84102ba0a2726a (patch) | |
tree | e4c000a5119a306ad11bd72eaf24737b6ee53d58 /gdb/NEWS | |
parent | 3194ca90fefda8e3e43cb11cb149a1e5c074d45c (diff) | |
download | gdb-44d9b0a174b08f283001f01aaf84102ba0a2726a.zip gdb-44d9b0a174b08f283001f01aaf84102ba0a2726a.tar.gz gdb-44d9b0a174b08f283001f01aaf84102ba0a2726a.tar.bz2 |
gdb/python: add PENDING_FRAMEPY_REQUIRE_VALID macro in py-unwind.c
This commit copies the pattern that is present in many other py-*.c
files: having a single macro to check that the Python object is still
valid.
This cleans up the code a little throughout the py-unwind.c file.
Some of the exception messages will change slightly with this commit,
though the type of the exceptions is still ValueError in all cases.
I started writing some tests for this change and immediately ran into
a problem: GDB would crash. It turns out that the PendingFrame
objects are not being marked as invalid!
In pyuw_sniffer where the pending frames are created, we make use of a
scoped_restore to invalidate the pending frame objects. However, this
only restores the pending_frame_object::frame_info field to its
previous value -- and it turns out we never actually give this field
an initial value, it's left undefined.
So, when the scoped_restore (called invalidate_frame) performs its
cleanup, it actually restores the frame_info field to an undefined
value. If this undefined value is not nullptr then any future
accesses to the PendingFrame object result in undefined behaviour and
most likely, a crash.
As part of this commit I now initialize the frame_info field, which
ensures all the new tests now pass.
Reviewed-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/NEWS')
0 files changed, 0 insertions, 0 deletions