Skip to content

Drop the SHT_NOTE section search from findExecFn - #368

Merged
godlygeek merged 1 commit into
bloomberg:mainfrom
godlygeek:drop_sht_note_section_search
Sep 24, 2026
Merged

godlygeek merged 1 commit into
bloomberg:mainfrom
godlygeek:drop_sht_note_section_search

Conversation

@godlygeek

Copy link
Copy Markdown
Contributor

findExecFn searched a core file's SHT_NOTE sections for the auxiliary vector before falling back to its PT_NOTE segments, on the grounds that "in a core file, the program headers may not be reliable". The section search could never find anything the segment search doesn't, so drop it.

It always failed because it gave an Elf_Data with a d_type of ELF_T_NHDR or ELF_T_NHDR8 to parseCoreExecfn, which passed that Elf_Data to gelf_getauxv, which rejects any Elf_Data whose d_type isn't ELF_T_AUXV. If it weren't rejected explicitly it still wouldn't work; we're passing a sequence of notes with leading headers to a function that expects to be pointed directly at a single note's payload.

Repairing it would have gained us nothing. For a core file the program headers are the authoritative structure, not the section headers:

  • Cores written by the kernel never have SHT_NOTE sections.
  • gcore cores have an SHT_NOTE section that matches the PT_NOTE segment.
  • If a core somehow did have an SHT_NOTE section but no PT_NOTE segments then findExecFn would never be reached: dwfl_core_file_attach requires a PT_NOTE program header, and the CoreFileAnalyzer constructor throws when dwfl_core_file_attach fails.

findExecFn searched a core file's SHT_NOTE sections for the auxiliary
vector before falling back to its PT_NOTE segments, on the grounds that
"in a core file, the program headers may not be reliable". The section
search could never find anything the segment search doesn't, so drop it.

It always failed because it gave an Elf_Data with a d_type of ELF_T_NHDR
or ELF_T_NHDR8 to parseCoreExecfn, which passed that Elf_Data to
gelf_getauxv, which rejects any Elf_Data whose d_type isn't ELF_T_AUXV.
If it weren't rejected explicitly it still wouldn't work; we're passing
a sequence of notes with leading headers to a function that expects to
be pointed directly at a single note's payload.

Repairing it would have gained us nothing. For a core file the program
headers are the authoritative structure, not the section headers:

- Cores written by the kernel never have SHT_NOTE sections.
- gcore cores have an SHT_NOTE section that matches the PT_NOTE segment.
- If a core somehow did have an SHT_NOTE section but no PT_NOTE segments
  then findExecFn would never be reached: dwfl_core_file_attach requires
  a PT_NOTE program header, and the CoreFileAnalyzer constructor throws
  when dwfl_core_file_attach fails.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
@godlygeek godlygeek self-assigned this Sep 24, 2026
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.78%. Comparing base (ba81703) to head (3ee0302).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #368   +/-   ##
=======================================
  Coverage   78.77%   78.78%           
=======================================
  Files          58       58           
  Lines        6715     6694   -21     
  Branches      635      630    -5     
=======================================
- Hits         5290     5274   -16     
+ Misses       1425     1420    -5     
Flag Coverage Δ
cpp 78.78% <100.00%> (+<0.01%) ⬆️
python 78.78% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@godlygeek
godlygeek requested review from a team and pablogsal September 24, 2026 21:34
@pablogsal

Copy link
Copy Markdown
Collaborator

Damn good find!

@godlygeek
godlygeek merged commit 5c594dc into bloomberg:main Sep 24, 2026
40 of 41 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants