Bug 971849
Summary: | Add $_signo convenience variable | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Denys Vlasenko <dvlasenk> | ||||||
Component: | gdb | Assignee: | Sergio Durigan Junior <sergiodj> | ||||||
Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 6.5 | CC: | dvlasenk, jan.kratochvil, mcermak, mfranc, mmilata | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | gdb-7.2-66.el6 | Doc Type: | Enhancement | ||||||
Doc Text: |
Cause: GDB did not had a proper way of representing the signal that caused the program being debugged to exit.
Consequence: There was no way to retrieve this information when using a corefile for debugging.
Fix: GDB now correctly exports the signal that caused the program being debugged to exit.
Result: The user can now obtain this information when using a corefile for debugging.
|
Story Points: | --- | ||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2014-10-14 07:27:57 UTC | Type: | Bug | ||||||
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
Denys Vlasenko
2013-06-07 12:14:44 UTC
GDB can decode full $_siginfo from NT_SIGINFO; I did not test it but assuming RHEL-6 kernel still did not produce NT_SIGINFO. As it is just a backward compatibility issue isn't it enough to use: eu-readelf -n ~/t/sleep.core | grep info.si_ info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11 Created attachment 758156 [details]
Proposed patch (untested)
(In reply to Jan Kratochvil from comment #1) > GDB can decode full $_siginfo from NT_SIGINFO; I did not test it but > assuming RHEL-6 kernel still did not produce NT_SIGINFO. Yes, I want to get at signo even on older kernels. > As it is just a backward compatibility issue isn't it enough to use: > eu-readelf -n ~/t/sleep.core | grep info.si_ > info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11 Python gdb plugin wouldn't know whether it is being run on a coredump or a live process which has crashed just now. How do you imagine to implement this in a not-horrifyingly hackish way? I really don't want to do something like: try: sig = gdb.parse_and_eval("$_siginfo.si_signo") except gdb.error: # Hmm, we are probably working on coredump.... # ... lets see whether we are running from the abrt and it provided us with signal number... try: sig = int(os.environ["ABRT_SIGNO_OF_THE_COREDUMP") except: ... with corresponding code elsewhere which sets $ABRT_SIGNO_OF_THE_COREDUMP. Created attachment 759707 [details]
Updated patch.
I built modified gdb-7.5.1-39.fc18 with this patch, it works for me.
Proposed upstream patch: http://sourceware.org/ml/gdb-patches/2013-06/msg00321.html Upstream patches accepted: - New convenience function $_isvoid: https://sourceware.org/ml/gdb-patches/2013-09/msg00457.html https://sourceware.org/ml/gdb-cvs/2013-09/msg00091.html regression fixes: https://sourceware.org/ml/gdb-patches/2013-09/msg00547.html https://sourceware.org/ml/gdb-cvs/2013-09/msg00102.html https://sourceware.org/ml/gdb-patches/2013-09/msg00470.html https://sourceware.org/ml/gdb-cvs/2013-09/msg00093.html - New variable $_exitsignal: https://sourceware.org/ml/gdb-patches/2013-10/msg00174.html https://sourceware.org/ml/gdb-cvs/2013-10/msg00041.html Now it is just a matter of backporting those patches to RHEL. Oh, just in case it wasn't clear: the name of the convenience variable accepted upstream has been changed from $_signo (as proposed in this bug report) to $_exitsignal. 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. http://rhn.redhat.com/errata/RHBA-2014-1534.html |