Bug 1197665
| Summary: | apply_frame_filter() wrong backport | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Matěj Cepl <mcepl> | ||||||||||||||||||||||||||
| Component: | gdb | Assignee: | Sergio Durigan Junior <sergiodj> | ||||||||||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Miroslav Franc <mfranc> | ||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||
| Version: | 7.0 | CC: | 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
Matěj Cepl
2015-03-02 10:56:01 UTC
Created attachment 997019 [details]
File: backtrace
Created attachment 997020 [details]
File: cgroup
Created attachment 997021 [details]
File: core_backtrace
Created attachment 997022 [details]
File: dso_list
Created attachment 997023 [details]
File: environ
Created attachment 997024 [details]
File: limits
Created attachment 997025 [details]
File: maps
Created attachment 997026 [details]
File: open_fds
Created attachment 997027 [details]
File: proc_pid_status
Created attachment 997028 [details]
File: var_log_messages
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 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).
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. 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.
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. Matej, can you confirm that the original problem has been fixed? I intend to check the patch in in the next few days. 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 *** Bug 1221133 has been marked as a duplicate of this bug. *** 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? 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 |