2019-01-01 14:01:51 +08:00
|
|
|
# Copyright (C) 2015-2019 Free Software Foundation, Inc.
|
2015-04-02 02:49:12 +08:00
|
|
|
|
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
# (at your option) any later version.
|
|
|
|
|
#
|
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
|
#
|
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
# This file is part of the GDB testsuite. It tests Python-based
|
|
|
|
|
# unwinding CLI.
|
|
|
|
|
|
|
|
|
|
load_lib gdb-python.exp
|
|
|
|
|
|
|
|
|
|
standard_testfile
|
|
|
|
|
|
2016-12-24 00:52:18 +08:00
|
|
|
if {[prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
|
2015-04-02 02:49:12 +08:00
|
|
|
return -1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Skip all tests if Python scripting is not enabled.
|
|
|
|
|
if { [skip_python_tests] } { continue }
|
|
|
|
|
|
|
|
|
|
set pyfile [gdb_remote_download host ${srcdir}/${subdir}/${testfile}.py]
|
|
|
|
|
|
|
|
|
|
if ![runto_main ] then {
|
2016-12-02 04:40:05 +08:00
|
|
|
fail "can't run to main"
|
2015-04-02 02:49:12 +08:00
|
|
|
return -1
|
|
|
|
|
}
|
|
|
|
|
|
Fix PR19927: Avoid unwinder recursion if sniffer uses calls parse_and_eval
This fixes the problem exercised by Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
This was originally exposed by the OpenJDK Python-based unwinder.
If an unwinder attempts to call parse_and_eval from within its
sniffing method, GDB's unwinding machinery enters infinite recursion.
However, parse_and_eval is a pretty reasonable thing to call, because
Python/Scheme-based unwinders will often need to read globals out of
inferior memory. The recursion happens because:
- get_current_frame() is called soon after the target stops.
- current_frame is NULL, and so we unwind it from the sentinel frame
(which is special and has level == -1).
- We reach get_prev_frame_if_no_cycle, which does cycle detection
based on frame id, and thus tries to compute the frame id of the new
frame.
- Frame id computation requires an unwinder, so we go through all
unwinder sniffers trying to see if one accepts the new frame (the
current frame).
- the unwinder's sniffer calls parse_and_eval().
- parse_and_eval depends on the selected frame/block, and if not set
yet, the selected frame is set to the current frame.
- get_current_frame () is called again. current_frame is still NULL,
so ...
- recurse forever.
In Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
gdb doesn't recurse forever simply because the Python unwinder
contains code to detect and stop the recursion itself. However, GDB
goes downhill from here, e.g., by showing the sentinel frame as
current frame (note the -1):
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
That "-1" frame level comes from this:
if (catch_exceptions (current_uiout, unwind_to_current_frame,
sentinel_frame, RETURN_MASK_ERROR) != 0)
{
/* Oops! Fake a current frame? Is this useful? It has a PC
of zero, for instance. */
current_frame = sentinel_frame;
}
which is bogus. It's never correct to set the current frame to the
sentinel frame. The only reason this has survived so long is that
getting here normally indicates something wrong has already happened
before and we fix that. And this case is no exception -- it doesn't
really matter how precisely we managed to get to that bogus code (it
has to do with the the stash), because anything after recursion
happens is going to be invalid.
So the fix is to avoid the recursion in the first place.
Observations:
#1 - The recursion happens because we try to do cycle detection from
within get_prev_frame_if_no_cycle. That requires computing the
frame id of the frame being unwound, and that itself requires
calling into the unwinders.
#2 - But, the first time we're unwinding from the sentinel frame,
when we reach get_prev_frame_if_no_cycle, there's no frame chain
at all yet:
- current_frame is NULL.
- the frame stash is empty.
Thus, there's really no need to do cycle detection the first time we
reach get_prev_frame_if_no_cycle, when building the current frame.
So we can break the recursion by making get_current_frame call a
simplified version of get_prev_frame_if_no_cycle that results in
setting the current_frame global _before_ computing the current
frame's id.
But, we can go a little bit further. As there's really no reason
anymore to compute the current frame's frame id immediately, we can
defer computing it to when some caller of get_current_frame might need
it. This was actually how the frame id was computed for all frames
before the stash-based cycle detection was added. So in a way, this
patch reintroduces the lazy frame id computation, but unlike before,
only for the case of the current frame, which turns out to be special.
This lazyness, however, requires adjusting
gdb.python/py-unwind-maint.exp, because that assumes unwinders are
immediately called as side effect of some commands. I didn't see a
need to preserve the behavior expected by that test (all it would take
is call get_frame_id inside get_current_frame), so I adjusted the
test.
gdb/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* frame.c (get_frame_id): Compute the frame id if not computed
yet.
(unwind_to_current_frame): Delete.
(get_current_frame): Use get_prev_frame_always_1 to get the
current frame and assert that that always succeeds.
(get_prev_frame_if_no_cycle): Skip cycle detection if returning
the current frame.
gdb/testsuite/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* gdb.python/py-unwind-maint.exp: Adjust tests to not expect that
unwinders are immediately called as side effect of "source" or
"disable unwinder" commands.
* gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
2016-09-06 01:41:38 +08:00
|
|
|
gdb_test "source ${pyfile}" "Python script imported" \
|
|
|
|
|
"import python scripts"
|
|
|
|
|
|
|
|
|
|
gdb_test_sequence "frame" "All unwinders enabled" {
|
2016-06-10 05:20:09 +08:00
|
|
|
"py_unwind_maint_ps_unwinder called"
|
|
|
|
|
"global_unwinder called"
|
Fix PR19927: Avoid unwinder recursion if sniffer uses calls parse_and_eval
This fixes the problem exercised by Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
This was originally exposed by the OpenJDK Python-based unwinder.
If an unwinder attempts to call parse_and_eval from within its
sniffing method, GDB's unwinding machinery enters infinite recursion.
However, parse_and_eval is a pretty reasonable thing to call, because
Python/Scheme-based unwinders will often need to read globals out of
inferior memory. The recursion happens because:
- get_current_frame() is called soon after the target stops.
- current_frame is NULL, and so we unwind it from the sentinel frame
(which is special and has level == -1).
- We reach get_prev_frame_if_no_cycle, which does cycle detection
based on frame id, and thus tries to compute the frame id of the new
frame.
- Frame id computation requires an unwinder, so we go through all
unwinder sniffers trying to see if one accepts the new frame (the
current frame).
- the unwinder's sniffer calls parse_and_eval().
- parse_and_eval depends on the selected frame/block, and if not set
yet, the selected frame is set to the current frame.
- get_current_frame () is called again. current_frame is still NULL,
so ...
- recurse forever.
In Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
gdb doesn't recurse forever simply because the Python unwinder
contains code to detect and stop the recursion itself. However, GDB
goes downhill from here, e.g., by showing the sentinel frame as
current frame (note the -1):
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
That "-1" frame level comes from this:
if (catch_exceptions (current_uiout, unwind_to_current_frame,
sentinel_frame, RETURN_MASK_ERROR) != 0)
{
/* Oops! Fake a current frame? Is this useful? It has a PC
of zero, for instance. */
current_frame = sentinel_frame;
}
which is bogus. It's never correct to set the current frame to the
sentinel frame. The only reason this has survived so long is that
getting here normally indicates something wrong has already happened
before and we fix that. And this case is no exception -- it doesn't
really matter how precisely we managed to get to that bogus code (it
has to do with the the stash), because anything after recursion
happens is going to be invalid.
So the fix is to avoid the recursion in the first place.
Observations:
#1 - The recursion happens because we try to do cycle detection from
within get_prev_frame_if_no_cycle. That requires computing the
frame id of the frame being unwound, and that itself requires
calling into the unwinders.
#2 - But, the first time we're unwinding from the sentinel frame,
when we reach get_prev_frame_if_no_cycle, there's no frame chain
at all yet:
- current_frame is NULL.
- the frame stash is empty.
Thus, there's really no need to do cycle detection the first time we
reach get_prev_frame_if_no_cycle, when building the current frame.
So we can break the recursion by making get_current_frame call a
simplified version of get_prev_frame_if_no_cycle that results in
setting the current_frame global _before_ computing the current
frame's id.
But, we can go a little bit further. As there's really no reason
anymore to compute the current frame's frame id immediately, we can
defer computing it to when some caller of get_current_frame might need
it. This was actually how the frame id was computed for all frames
before the stash-based cycle detection was added. So in a way, this
patch reintroduces the lazy frame id computation, but unlike before,
only for the case of the current frame, which turns out to be special.
This lazyness, however, requires adjusting
gdb.python/py-unwind-maint.exp, because that assumes unwinders are
immediately called as side effect of some commands. I didn't see a
need to preserve the behavior expected by that test (all it would take
is call get_frame_id inside get_current_frame), so I adjusted the
test.
gdb/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* frame.c (get_frame_id): Compute the frame id if not computed
yet.
(unwind_to_current_frame): Delete.
(get_current_frame): Use get_prev_frame_always_1 to get the
current frame and assert that that always succeeds.
(get_prev_frame_if_no_cycle): Skip cycle detection if returning
the current frame.
gdb/testsuite/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* gdb.python/py-unwind-maint.exp: Adjust tests to not expect that
unwinders are immediately called as side effect of "source" or
"disable unwinder" commands.
* gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
2016-09-06 01:41:38 +08:00
|
|
|
"#0 main"
|
2016-06-10 05:20:09 +08:00
|
|
|
}
|
2015-04-02 02:49:12 +08:00
|
|
|
|
|
|
|
|
gdb_test_sequence "info unwinder" "Show all unwinders" {
|
|
|
|
|
"Global:"
|
|
|
|
|
" global_unwinder"
|
|
|
|
|
"Progspace .*py-unwind-maint:"
|
|
|
|
|
"py_unwind_maint_ps_unwinder"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_breakpoint ${srcfile}:[gdb_get_line_number "next-line"]
|
|
|
|
|
|
|
|
|
|
gdb_test_sequence "continue" "Unwinders called" {
|
|
|
|
|
"py_unwind_maint_ps_unwinder called"
|
|
|
|
|
"global_unwinder called"
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-10 05:20:09 +08:00
|
|
|
gdb_test_sequence "disable unwinder global .*" "Unwinder disabled" {
|
|
|
|
|
"1 unwinder disabled"
|
|
|
|
|
}
|
2015-04-02 02:49:12 +08:00
|
|
|
|
|
|
|
|
gdb_test_sequence "info unwinder" "Show with global unwinder disabled" {
|
|
|
|
|
"Global:"
|
|
|
|
|
" global_unwinder \\[disabled\\]"
|
|
|
|
|
"Progspace .*py-unwind-maint:"
|
|
|
|
|
" py_unwind_maint_ps_unwinder"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_test_sequence "where" "Global unwinder disabled" {
|
|
|
|
|
"py_unwind_maint_ps_unwinder called\r\n#0 main"
|
|
|
|
|
}
|
