mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-24 18:44:20 +08:00
aa36950904
When running GDB tests under Valgrind, various tests are failing due
to invalid memory access.
Here is the stack trace reported by Valgrind, for gdb.base/freebpcmd.exp :
==18658== Invalid read of size 8
==18658== at 0x7F9107: is_main (signalmodule.c:195)
==18658== by 0x7F9107: PyOS_InterruptOccurred (signalmodule.c:1730)
==18658== by 0x3696E2: check_quit_flag() (extension.c:829)
==18658== by 0x36980B: restore_active_ext_lang(active_ext_lang_state*) (extension.c:782)
==18658== by 0x48F617: gdbpy_enter::~gdbpy_enter() (python.c:235)
==18658== by 0x47BB71: add_thread_object(thread_info*) (object.h:470)
==18658== by 0x53A84D: operator() (std_function.h:687)
==18658== by 0x53A84D: notify (observable.h:106)
==18658== by 0x53A84D: add_thread_silent(ptid_t) (thread.c:311)
==18658== by 0x3CD954: inf_ptrace_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&
, char**, int) (inf-ptrace.c:139)
==18658== by 0x3FE644: linux_nat_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&,
char**, int) (linux-nat.c:1094)
==18658== by 0x3D5727: run_command_1(char const*, int, run_how) (infcmd.c:633)
==18658== by 0x2C05D1: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1948)
==18658== by 0x53F29F: execute_command(char const*, int) (top.c:639)
==18658== by 0x3638EB: command_handler(char const*) (event-top.c:586)
==18658== by 0x36468C: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:771)
==18658== by 0x36407C: gdb_rl_callback_handler(char*) (event-top.c:217)
==18658== by 0x5B2A1F: rl_callback_read_char (callback.c:281)
==18658== by 0x36346D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:175)
==18658== by 0x363F70: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:192)
==18658== by 0x3633AF: stdin_event_handler(int, void*) (event-top.c:514)
==18658== by 0x362504: gdb_wait_for_event (event-loop.c:857)
==18658== by 0x362504: gdb_wait_for_event(int) (event-loop.c:744)
==18658== by 0x362676: gdb_do_one_event() [clone .part.11] (event-loop.c:321)
==18658== by 0x3627AD: gdb_do_one_event (event-loop.c:303)
==18658== by 0x3627AD: start_event_loop() (event-loop.c:370)
==18658== by 0x41D35A: captured_command_loop() (main.c:381)
==18658== by 0x41F2A4: captured_main (main.c:1224)
==18658== by 0x41F2A4: gdb_main(captured_main_args*) (main.c:1239)
==18658== by 0x227D0A: main (gdb.c:32)
==18658== Address 0x10 is not stack'd, malloc'd or (recently) free'd
The problem seems to be created by gdbpy_enter::~gdbpy_enter () releasing the GIL lock
too early:
~gdbpy_enter () does:
...
PyGILState_Release (m_state);
python_gdbarch = m_gdbarch;
python_language = m_language;
restore_active_ext_lang (m_previous_active);
}
So, it releases the GIL lock, does 2 assignments and then leads to the following
call sequence:
restore_active_ext_lang => check_quit_flag => python.c gdbpy_check_quit_flag
=> PyOS_InterruptOccurred => is_main.
is_main code is:
static int
is_main(_PyRuntimeState *runtime)
{
unsigned long thread = PyThread_get_thread_ident();
PyInterpreterState *interp = _PyRuntimeState_GetThreadState(runtime)->interp;
return (thread == runtime->main_thread
&& interp == runtime->interpreters.main);
}
The macros and functions to access the thread state are documented as:
/* Variable and macro for in-line access to current thread
and interpreter state */
#define _PyRuntimeState_GetThreadState(runtime) \
((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current))
/* Get the current Python thread state.
Efficient macro reading directly the 'gilstate.tstate_current' atomic
variable. The macro is unsafe: it does not check for error and it can
return NULL.
The caller must hold the GIL.
See also PyThreadState_Get() and PyThreadState_GET(). */
#define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime)
So, we see that GDB releases the GIL and then potentially calls
_PyRuntimeState_GetThreadState that needs the GIL.
It is not very clear why the problem is only observed when running under
Valgrind. Probably caused by the slowdown due to Valgrind and/or to the 'single
thread' scheduling by Valgrind.
This patch fixes the crashes by releasing the GIT lock later.
2019-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/python.c (gdbpy_enter::~gdbpy_enter): Release GIL after
restore_active_ext_lang, as GIL is needed for (indirectly)
called PyOS_InterruptOccurred.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.