Bug 1125990
| Summary: | RFE: Add support for kernel source code, aka 'gdb list' | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Dave Wysochanski <dwysocha> |
| Component: | retrace-server | Assignee: | abrt <abrt-devel-list> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | el6 | CC: | atomlin, brhatiga, fsorenso, msuchy, nobody, smayhew, stalexan, vgaikwad |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-30 14:55:25 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: | |||
|
Description
Dave Wysochanski
2014-08-01 14:31:21 UTC
This is definitely a useful feature - there have many times when I've opened a vmcore and wished this feature was available. The ability to quickly look at the faulting source code could result in an equally quick confirmation of a known problem without needing to find a repository and checkout the correct branch. But with most vmcore analyses I do it's only a matter of time before I need the full kernel source indexed with cscope/tags so I can search it and the recent change history too (and not to mention other trees to compare with too). So while this is a very convenient feature it does have it's limits. This is indeed an interesting feature, that can increase our efficiency when doing the "first touch" on a vmcore and, as Lachlan points out, quickly confirm known issues, or checking the vmcore sources against the most current ones. Since many parts of the kernel remain unchanged between minor releases and z-streams, an engineer could be very efficient with a checkout of the most recent sources and comparing it against what crash shows for the vmcore. If the sources are the same for the problem under consideration, the engineer can quickly confirm or discard a hypothesis without waiting for the local checkout for that particular release, or decide to check the commit log for the particular file under consideration to quickly determine why something changed. My only concern would be how efficient we can make the sources storage space. I wonder how much we can use hardlinking and deduplication to keep that manageable. Yes I was thinking it would be useful to have the source even if all it was used for was listing out the source code of the faulting task. Having the source right there automatically for every vmcore also opens more possibilities for automated analysis. The other thing is it just feels incomplete to me to have a core (userspace or kernel) analysis system without source code integration. Point taken that a lot of people that work on vmcores have their own trees and/or may need more than just the one tree. I would like to hear from some kernel TSE and non-SEGs. This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of EPEL please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |