Simon Marchi [Sat, 21 Jan 2017 01:39:08 +0000 (20:39 -0500)]
Fix python-interactive with Python 3.6
New in v2:
- Define PyMem_RawMalloc as PyMem_Malloc for Python < 3.4 and use
PyMem_RawMalloc in the code.
Since Python 3.4, the callback installed in PyOS_ReadlineFunctionPointer
should return a value allocated with PyMem_RawMalloc instead of
PyMem_Malloc. The reason is that PyMem_Malloc must be called with the
Python Global Interpreter Lock (GIL) held, which is not the case in the
context where this function is called. PyMem_RawMalloc was introduced
for cases like this.
In Python 3.6, it looks like they added an assert to verify that
PyMem_Malloc was not called without the GIL. The consequence is that
typing anything in the python-interactive mode of gdb crashes the
process. The same behavior was observed with the official package on
Arch Linux as well as with a manual Python build on Ubuntu 14.04.
This is what is shown with a debug build of Python 3.6 (the error with a
non-debug build is far less clear):
(gdb) pi
>>> print(1)
Fatal Python error: Python memory allocator called without holding the GIL
#0 0x00007ffff618bc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff618f028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6b104d6 in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1457
#3 0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972
#4 0x00007ffff6a3804e in _PyMem_DebugFree (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, ptr=0x24f8830) at Objects/obmalloc.c:1994
#5 0x00007ffff6a38e1d in PyMem_Free (ptr=<optimized out>) at Objects/obmalloc.c:442
#6 0x00007ffff6b866c6 in _PyFaulthandler_Fini () at ./Modules/faulthandler.c:1369
#7 0x00007ffff6b104bd in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1431
#8 0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972
#9 0x00007ffff6a37aa3 in _PyMem_DebugMalloc (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, nbytes=5) at Objects/obmalloc.c:1980
#10 0x00007ffff6a38d91 in PyMem_Malloc (size=<optimized out>) at Objects/obmalloc.c:418
#11 0x000000000064dbe2 in gdbpy_readline_wrapper (sys_stdin=0x7ffff6514640 <_IO_2_1_stdin_>, sys_stdout=0x7ffff6514400 <_IO_2_1_stdout_>, prompt=0x7ffff4d4f7d0 ">>> ")
at /home/emaisin/src/binutils-gdb/gdb/python/py-gdb-readline.c:75
The documentation is very clear about it [1] and it was also mentioned
in the "What's New In Python 3.4" page [2].
Yao Qi [Fri, 20 Jan 2017 13:00:52 +0000 (13:00 +0000)]
Throw SJ/LJ exception on error in disassembly
PR 20939 reports that GDB will abort on memory error in disassembly,
(gdb) disassemble 0x0,+4
Dump of assembler code from 0x0 to 0x4:
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
0x0000000000000000: Aborted
(gdb) guile (print (arch-disassemble arch 0 #:size 4))^M
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'^M
ERROR: Process no longer exists
This patch fixes PR 20939 by catching C++ exception, throwing SJ/LJ
exception in the call back passed to C functions of opcodes, and
catching SJ/LJ exception in gdb, and throw exception.
rather than "backport" the fix to this PR I posted for mainline
https://sourceware.org/ml/gdb-patches/2017-01/msg00288.html because the
fix for mainline includes 1) some changes to opcodes, 2) some refactors
in C++. All of them are risky to backport to 7.12 branch.
With this patch applied to 7.12 branch, GDB doesn't abort on memory error
in disassembly. It fixes some test failures in gdb.guile/scm-disasm.exp
and gdb.python/py-arch.exp on aarch64-linux.
-ERROR: Process no longer exists
-UNRESOLVED: gdb.guile/scm-disasm.exp: test bad memory access
+PASS: gdb.guile/scm-disasm.exp: test bad memory access
-ERROR: Process no longer exists
-UNRESOLVED: gdb.python/py-arch.exp: test bad memory access
+PASS: gdb.python/py-arch.exp: test bad memory access
I'll add the scm-disasm test to master later.
gdb:
2017-01-20 Yao Qi <yao.qi@linaro.org>
PR gdb/20939
* disasm.c (dis_asm_memory_error): Catch the error and rethrow
it as a SJ/LJ exception. Add GDB_NOEXCEPT.
(disasm_print_insn_noexcept): New function.
(disasm_print_insn): New function.
(gdb_pretty_print_insn): Call disasm_print_insn instead of
gdbarch_print_insn.
(gdb_print_insn): Likewise.
(gdb_buffered_insn_length): Likewise.
* event-top.c (GDB_NOEXCEPT): Move it to ...
* exceptions.h (GDB_NOEXCEPT): ... here.
* guile/scm-disasm.c (gdbscm_disasm_memory_error): Remove.
(gdbscm_print_insn_from_port): Don't set di.memory_errro_func.
Call disasm_print_insn rather than gdbarch_print_insn.
Joel Brobecker [Sun, 1 Jan 2017 07:05:52 +0000 (11:05 +0400)]
update copyright year range in GDB files
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files (the first
part is ommitted on this branch).
Pedro Alves [Tue, 20 Dec 2016 19:18:15 +0000 (19:18 +0000)]
gdb: Fix C and C++03 builds
The readline/sjlj-exceptions fix added an unconditional use of
noexcept, but that's only valid C++11, and 7.12 must build with C and
C++03 too. Fix this by adding a GDB_EXCEPT macro that compiles away
to nothing in C, and to throw() in C++03, which I've confirmed fixes
the original issue just the same as noexcept, with GCC 7 + -std=gnu+03
+ sjlj-exceptions.
gdb/ChangeLog:
2016-12-20 Pedro Alves <palves@redhat.com>
PR gdb/20977
* event-top.c (GDB_NOEXCEPT): Define.
(gdb_rl_callback_read_char_wrapper_noexcept): Use GDB_NOEXCEPT
instead of noexcept and use (void) instead of ().
(gdb_rl_callback_handler): Use GDB_NOEXCEPT instead of noexcept.
Pedro Alves [Tue, 20 Dec 2016 16:25:54 +0000 (16:25 +0000)]
Fix longjmp across readline w/ --enable-sjlj-exceptions toolchains
Nowadays, GDB propagates C++ exceptions across readline using
setjmp/longjmp 89525768cd08 ("Propagate GDB/C++ exceptions across
readline using sj/lj-based TRY/CATCH") because DWARF-based unwinding
can't cross C functions compiled without -fexceptions (see details
from the commit above).
Unfortunately, toolchains that use SjLj-based C++ exceptions got
broken with that fix, because _Unwind_SjLj_Unregister, which is put at
the exit of a function, is not executed due to the longjmp added by
that commit.
(gdb) [New Thread 2936.0xb80]
kill
Thread 1 received signal SIGSEGV, Segmentation fault.
0x03ff662b in ?? ()
top?bt 15
#0 0x03ff662b in ?? ()
#1 0x00526b92 in stdin_event_handler (error=0, client_data=0x172ed8)
at ../../binutils-gdb/gdb/event-top.c:555
#2 0x00525a94 in handle_file_event (ready_mask=<optimized out>,
file_ptr=0x3ff5cb8) at ../../binutils-gdb/gdb/event-loop.c:733
#3 gdb_wait_for_event (block=block@entry=1)
at ../../binutils-gdb/gdb/event-loop.c:884
#4 0x00525bfb in gdb_do_one_event ()
at ../../binutils-gdb/gdb/event-loop.c:347
#5 0x00525ce5 in start_event_loop ()
at ../../binutils-gdb/gdb/event-loop.c:371
#6 0x0051fada in captured_command_loop (data=0x0)
at ../../binutils-gdb/gdb/main.c:324
#7 0x0051cf5d in catch_errors (
func=func@entry=0x51fab0 <captured_command_loop(void*)>,
func_args=func_args@entry=0x0,
errstring=errstring@entry=0x7922bf <VEC_interp_factory_p_quick_push(VEC_inte rp_factory_p*, interp_factory*, char const*, unsigned int)::__PRETTY_FUNCTION__+351> "", mask=mask@entry=RETURN_MASK_ALL)
at ../../binutils-gdb/gdb/exceptions.c:236
#8 0x00520f0c in captured_main (data=0x328feb4)
at ../../binutils-gdb/gdb/main.c:1149
#9 gdb_main (args=args@entry=0x328feb4) at ../../binutils-gdb/gdb/main.c:1159
#10 0x0071e400 in main (argc=1, argv=0x171220)
at ../../binutils-gdb/gdb/gdb.c:32
Fix this by making the functions involved in setjmp/longjmp as
noexcept, so that the compiler knows it doesn't need to emit the
_Unwind_SjLj_Register / _Unwind_SjLj_Unregister calls for C++
exceptions.
Tested on x86_64 Fedora 23 with:
- GCC 5.3.1 w/ DWARF-based exceptions.
- GCC 7 built with --enable-sjlj-exceptions.
gdb/ChangeLog:
2016-12-20 Pedro Alves <palves@redhat.com>
Yao Qi <yao.qi@linaro.org>
PR gdb/20977
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept): New
noexcept function, factored out from ...
(gdb_rl_callback_read_char_wrapper): ... this.
(gdb_rl_callback_handler): Mark noexcept.