diff options
| author | Pedro Alves <palves@redhat.com> | 2017-04-13 16:15:34 +0100 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2017-04-13 16:15:34 +0100 |
| commit | 441d7c93782a1b1877bfa903dc8da56a6041bfb4 (patch) | |
| tree | 649f20b5b7af4565769c44e5eae6e2e19bbcff21 /gdb/thread.c | |
| parent | 7296a62a2a237f6b1ad8db8c38b090e9f592c8cf (diff) | |
| download | gdb-441d7c93782a1b1877bfa903dc8da56a6041bfb4.zip gdb-441d7c93782a1b1877bfa903dc8da56a6041bfb4.tar.gz gdb-441d7c93782a1b1877bfa903dc8da56a6041bfb4.tar.bz2 | |
watch_command_1: Fix dangling frame access
While working on some changes to switch_to_thread, I inadvertently
make switch_to_thread call reinit_frame_cache more frequently, even
when the thread didn't change. This exposed a latent bug in
watch_command_1, where we're referencing a frame after
creating/inserting breakpoints, which potentially calls
reinit_frame_cache if it needs to install breakpoints with a different
thread selected.
Handle this similarly to how it's already handled in other similar
cases. I.e., save any frame-related information we might need before
creating a breakpoint.
gdb/ChangeLog:
2017-04-13 Pedro Alves <palves@redhat.com>
* breakpoint.c (watch_command_1): Save watchpoint-frame info
before calling create_internal_breakpoint.
Diffstat (limited to 'gdb/thread.c')
0 files changed, 0 insertions, 0 deletions