Bug 1197665

Summary: apply_frame_filter() wrong backport
Product: Red Hat Enterprise Linux 7 Reporter: Matěj Cepl <mcepl>
Component: gdbAssignee: Sergio Durigan Junior <sergiodj>
Status: CLOSED ERRATA QA Contact: Miroslav Franc <mfranc>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: gdb-bugs, jan.kratochvil, mcepl, mfranc, ohudlick, palves, sergiodj, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://faf-report.itos.redhat.com/reports/bthash/047c35c296e9733064e0e0072e549fdbae6e997e
Whiteboard: abrt_hash:bf3ef9266883a16e9a8b9845671f2d65a0bdf2ed
Fixed In Version: gdb-7.6.1-69.el7 Doc Type: Bug Fix
Doc Text:
The code to register a new Python FrameFilter on GDB was incorrectly initializing an important variable that could be needed later during the execution of the debugger. Consequently, using Python FrameFilters could cause an internal error on GDB when requesting a full backtrace of the program being debugged. This internal error would then affect the reliability of the debugging session and make it impossible to continue debugging the program. This bug has been fixed, GDB is now correctly initializing this important internal variable when a Python FrameFilter is registered to be used, and the user can now safely request full backtraces.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 13:03:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages
none
output of gdb --pid=$(pidof evolution)
none
output of gdb none

Description Matěj Cepl 2015-03-02 10:56:01 UTC
Description of problem:
Running abrt on the hexchat application carash; gnome-abrt  was downloading debuginfo packages (because, of course, our internal tracing server doesn't have debuginfo for EPEL app).

Version-Release number of selected component:
gdb-7.6.1-64.el7

Additional info:
reporter:       libreport-2.1.11
backtrace_rating: 4
cmdline:        gdb -batch -iex 'add-auto-load-safe-path /var/cache/abrt-di/usr/lib/debug' -iex 'add-auto-load-scripts-directory /var/cache/abrt-di/usr/lib/debug' -ex 'set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug' -ex 'file /usr/bin/hexchat' -ex 'core-file ./coredump' -ex 'thread apply all backtrace 1024 full' -ex 'info sharedlib' -ex 'print (char*)__abort_msg' -ex 'print (char*)__glib_assert_msg' -ex 'info all-registers' -ex disassemble
crash_function: dump_core
executable:     /usr/bin/gdb
kernel:         3.10.0-229.el7.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #2 dump_core at ../../gdb/utils.c:761
 #3 internal_vproblem at ../../gdb/utils.c:919
 #4 internal_verror at ../../gdb/utils.c:944
 #5 internal_error at ../../gdb/utils.c:954
 #6 gdbarch_auto_charset at ../../gdb/gdbarch.c:4229
 #7 target_charset at ../../gdb/charset.c:403
 #8 unicode_to_target_string at ../../gdb/python/py-utils.c:156
 #9 python_string_to_target_string at ../../gdb/python/py-utils.c:185
 #10 frapy_read_var at ../../gdb/python/py-frame.c:447
 #11 call_function at /usr/src/debug/Python-2.7.5/Python/ceval.c:4098

Comment 1 Matěj Cepl 2015-03-02 10:56:05 UTC
Created attachment 997019 [details]
File: backtrace

Comment 2 Matěj Cepl 2015-03-02 10:56:07 UTC
Created attachment 997020 [details]
File: cgroup

Comment 3 Matěj Cepl 2015-03-02 10:56:09 UTC
Created attachment 997021 [details]
File: core_backtrace

Comment 4 Matěj Cepl 2015-03-02 10:56:11 UTC
Created attachment 997022 [details]
File: dso_list

Comment 5 Matěj Cepl 2015-03-02 10:56:12 UTC
Created attachment 997023 [details]
File: environ

Comment 6 Matěj Cepl 2015-03-02 10:56:14 UTC
Created attachment 997024 [details]
File: limits

Comment 7 Matěj Cepl 2015-03-02 10:56:16 UTC
Created attachment 997025 [details]
File: maps

Comment 8 Matěj Cepl 2015-03-02 10:56:18 UTC
Created attachment 997026 [details]
File: open_fds

Comment 9 Matěj Cepl 2015-03-02 10:56:19 UTC
Created attachment 997027 [details]
File: proc_pid_status

Comment 10 Matěj Cepl 2015-03-02 10:56:21 UTC
Created attachment 997028 [details]
File: var_log_messages

Comment 12 Matěj Cepl 2015-03-21 15:29:11 UTC
Another user experienced a similar problem:

Trying to generate backtrace from the running Evolution.

Something like

gdb -nx --batch -ex 'thread apply all backtrace' --pid=$(pidof evolution)|&tee evolution-backtrace.txt

reporter:       libreport-2.1.11
backtrace_rating: 4
cmdline:        gdb -batch -iex 'add-auto-load-safe-path /var/cache/abrt-di/usr/lib/debug' -iex 'add-auto-load-scripts-directory /var/cache/abrt-di/usr/lib/debug' -ex 'set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug' -ex 'file /usr/bin/nautilus' -ex 'core-file ./coredump' -ex 'thread apply all backtrace 1024 full' -ex 'info sharedlib' -ex 'print (char*)__abort_msg' -ex 'print (char*)__glib_assert_msg' -ex 'info all-registers' -ex disassemble
crash_function: dump_core
executable:     /usr/bin/gdb
kernel:         3.10.0-229.el7.x86_64
package:        gdb-7.6.1-64.el7
reason:         gdb killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            1000

Comment 13 Jan Kratochvil 2015-03-21 15:56:49 UTC
gdb-upstream-framefilters-1of2.patch:
+apply_frame_filter():
+  struct gdbarch *gdbarch = NULL;
+  cleanups = ensure_python_env (gdbarch, current_language);
+  TRY_CATCH (except, RETURN_MASK_ALL)
+    {
+      gdbarch = get_frame_arch (frame);
+    }

This really cannot work, ensure_python_env is called with gdbarch=NULL.

For some reason initial upstream commit already has it right:
1e611234ee3f4a1d2434f3fe7530cab87c936e0d

This buggy backport comes from:
commit 89fbbfccaf093284eadb1af638486ee5b1701a81
Author: Jan Kratochvil <jan.kratochvil>
Date:   Tue May 21 13:54:33 2013 +0200
+# Backported Python frame filters (Phil Muldoon).
+Patch836: gdb-upstream-framefilters-1of2.patch
+* Tue May 21 2013 Jan Kratochvil <jan.kratochvil> - 7.6-30.fc19
+- Backported Python frame filters (Phil Muldoon).

Comment 14 Sergio Durigan Junior 2015-03-24 18:27:13 UTC
I actually see the same error on 1e611234ee3f4a1d2434f3fe7530cab87c936e0d.  This has been fixed by:

commit 21909fa1c6d934bfa0c7ad3ef95909db48f6f756
Author: Tom Tromey <tromey>
Date:   Wed Jan 22 08:10:01 2014 -0700

So the right fix would be to backport this patch.

Comment 15 Matěj Cepl 2015-03-24 22:36:26 UTC
Created attachment 1006042 [details]
output of gdb --pid=$(pidof evolution)

Unfortunately, gdb-7.6.1-65.el7.x86_64 doesn't fix the issue, or at least I have still Python exceptions in the output.

Comment 16 Sergio Durigan Junior 2015-03-24 22:57:27 UTC
I don't see GDB crashing anymore on your output.  This exception happens when GDB cannot locate a frame block refered by the backtrace (GDB then raises a Python exception), but the original problem has been fixed by the backported patch.

FTR: I provided a scratch build for Matej.

Comment 17 Sergio Durigan Junior 2015-05-05 22:55:29 UTC
Matej, can you confirm that the original problem has been fixed?  I intend to check the patch in in the next few days.

Comment 18 Matěj Cepl 2015-05-13 12:32:42 UTC
Created attachment 1025041 [details]
output of gdb

(In reply to Sergio Durigan Junior from comment #17)
> Matej, can you confirm that the original problem has been fixed?  I intend
> to check the patch in in the next few days.

Is this what you want? I got it with gdb-7.6.1-65.el7.x86_64

Comment 19 Sergio Durigan Junior 2015-05-19 19:17:36 UTC
*** Bug 1221133 has been marked as a duplicate of this bug. ***

Comment 20 Vladimir Benes 2015-05-20 11:11:44 UTC
I've updated from release 64 to gdb-7.6.1-68.el7.x86_64 but I still can reproduce the crash. Is it supposed to be fixed in any of these versions?

Comment 25 errata-xmlrpc 2015-11-19 13:03:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2089.html