[stable] Fixes for bugs found in QA testing #158
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The module_has_debuginfo() function is heuristic and only checks the first symbol to see whether drgn knows of it. Let's increase this to the first 5 symbols (truly, just a magic number) which eliminates some observed false positives in the wild. I'm willing to do this somewhat scattershot approach beacuse we're not far from switching to drgn's new Module API. This will allow us to drop this heuristic function and just query the Module API for the status of the debuginfo file. Orabug: 37894843 Signed-off-by: Stephen Brennan <[email protected]>
oracle-contributor-agreement
bot
added
the
OCA Verified
|
All CI tests are passing. |
The heuristic approach for detecting whether DWARF debuginfo is loaded for kernel modules proved to be even less reliable than previously expected. For instance, on some kernel versions, over half of kernel modules are wrongly detected as "missing" debuginfo. To avoid this causing problems in corelens, let's add the less elegant, but obvious solution. Keep track of which modules we've loaded debuginfo, and consult this set first. Fall back to heuristic detection in case we did not record that we had loaded debuginfo. This is unlikely, given that the common use cases of drgn-tools (corelens and the CLI) both rely on the APIs here to load debuginfo. Orabug: 37894843 Signed-off-by: Stephen Brennan <[email protected]>
While we do have logic to catch ctrl-c and broken pipe errors, the logic doesn't apply to /usr/bin/corelens, due to the way the script is created by pip/setuptools. Fix this, and while we're at it, de-mystify a comment I wrote regarding the corelens startup sequence. Orabug: 37879205 Signed-off-by: Stephen Brennan <[email protected]>
In 60c868eff2bc5 ("arm64/cpufeature: Store elf_hwcaps as a bitmap rather
than unsigned long") the elf_hwcap variable on aarch64 was converted to
a bitmap. Update the cpuinfo module to handle this.
Orabug: 37879692
Signed-off-by: Stephen Brennan <[email protected]>
The current code implicitly assumes that the system is using rds_rdma. If the module runs on a system with rds_tcp loaded, we get a traceback ending in the following error: KeyError: 'rds_ib_devices' I don't know whether rds_tcp support is desired at this time, but at a minimum, corelens should not throw a traceback. So, explicitly require rds_rdma for this module. Now, for rds_tcp, we get the following standard corelens warning that explains the situation. warning: rds skipped because 'rds, rds_rdma' was (were) not (all) loaded in the kernel Orabug: 37894843 Signed-off-by: Stephen Brennan <[email protected]>
Ah, the classic Python experience: deprecations for seemingly no reason. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
force-pushed
the
qa_bugs_stable
branch
from
a38fbd9 to
ae9e0e9
Compare
biger410
approved these changes
Apr 30, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Same as #157 but applies to the
stable/v2.1.xbranch. The bug numbers are different for tracking.