Re: [PATCH] libdw: Fix dwarf_getscopes memory leak on error
Hi, On Wed, 2023-02-22 at 23:39 +0100, Mark Wielaard wrote: > When there is an error in dwarf_getscopes after the initial scopes > have been allocated, e.g. when looking for the inlined scopes, then > the scopes would leak. Fix this by explicitly free the scopes on error. > > https://sourceware.org/bugzilla/show_bug.cgi?id=29434 I pushed this. Cheers, Mark
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Mark Wielaard --- I hope this (plus the other changes to dwarf_getscopes) will fix the original issue too. It should be part of 0.189 (which should be released this week). If it didn't solve the issue please feel free to reopen this bug or file a new one. commit e24d8a4a3ea106608bb3e8d33c4639cf71d0f08d Author: Mark Wielaard Date: Wed Feb 22 23:34:00 2023 +0100 libdw: Fix dwarf_getscopes memory leak on error When there is an error in dwarf_getscopes after the initial scopes have been allocated, e.g. when looking for the inlined scopes, then the scopes would leak. Fix this by explicitly free the scopes on error. https://sourceware.org/bugzilla/show_bug.cgi?id=29434 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH v3] strip: keep .ctf section in stripped file
Hi Guillermo, CCed Nick to see if he knows why binutils strip does what it does. On Fri, 2023-02-24 at 10:48 -0600, Guillermo E. Martinez wrote: > On Fri, Feb 24, 2023 at 12:51:25PM +0100, Mark Wielaard wrote: > > > > On Thu, Feb 23, 2023 at 12:42:37PM -0600, Guillermo E. Martinez via > > Elfutils-devel wrote: > > > This is the third version of the patch to avoid remove the CTF section in > > > stripped files. Changes from v2: > > > > > > - Rebased from master. > > > > > > Please let me know your thoughts. > > > > > > CTF debug format was designed to be present in stripped files, so > > > this section should not be removed, so a new --remove-ctf option > > > is added to indicate explicitly that .ctf section will be stripped > > > out from binary file. > > > > Since the way to recognize a CTF section is by name ".ctf" does it > > really need a new option? eu-strip already has: > > > > --keep-section=SECTION Keep the named section. SECTION is an extended > >wildcard pattern. May be given more than once. > > > > -R, --remove-section=SECTION Remove the named section. SECTION is an > >extended wildcard pattern. May be given more > > than > >once. Only non-allocated sections can be > >removed. > > > > Do you really need a new option? Or could you use an explicit > > --keep-section=.ctf and/or --remove-section=.ctf ? > > > > Oh, I see, thanks for your comment!. My intention with this patch is to > replicate the same proceeding by _default_ implemented in `binutils strip' > tool, it is: not remove CTF section, except it is indicated explicitly. O, this surprises me. I wasn't aware binutils strip keeps unallocated sections by default. But apparently it does. It doesn't seem specific to ".ctf". Do you know why? This seems counter to how strip is supposed to behave, at least how I understand it. eu-strip removes any non-allocated section (unless -g is given) which isn't referenced through a sh_link or sh_info (with SHF_INFO_LINK set) from a section that isn't removed. I assumed binutils strip would behave the same. See also http://www.linker-aliens.org/blogs/ali/entry/how_to_strip_an_elf/ (So one idea might be to reference the .ctf section through sh_link from e.g. the .text or .data section to signal it should be kept?) > Of course, if you think it is not really a good idea, I can propose a > patch to change the invocation of `eu-strip' in `find-debuginfo.sh' to > preserve CTF section as you showed above, when it generates debug > packages. Note that find-debuginfo already has: Use --keep-section SECTION or --remove-section SECTION to explicitly keep a (non-allocated) section in the main executable or explicitly remove it into the .debug file. SECTION is an extended wildcard pattern. Both options can be given more than once. Cheers, Mark
Re: [PATCH v3] strip: keep .ctf section in stripped file
Hi Mark, Oh, I see, thanks for your comment!. My intention with this patch is to replicate the same proceeding by _default_ implemented in `binutils strip' tool, it is: not remove CTF section, except it is indicated explicitly. O, this surprises me. I wasn't aware binutils strip keeps unallocated sections by default. But apparently it does. It doesn't seem specific to ".ctf". Do you know why? This seems counter to how strip is supposed to behave, at least how I understand it. I do not know why and I agree that it looks like a bug. Hmm, do you have a specific example in mind ? Cheers Nick
Re: [PATCH v3] strip: keep .ctf section in stripped file
Hi Mark, O, this surprises me. I wasn't aware binutils strip keeps unallocated sections by default. But apparently it does. It doesn't seem specific to ".ctf". Do you know why? This seems counter to how strip is supposed to behave, at least how I understand it. Actually thinking about it, there are a few important un-allocated sections that ought to be kept in a binary. For example .gnu_debuglink and .shstrtab. So maybe deleting unallocated sections by default is not such a good idea. Cheers Nick
☠ Buildbot (Sourceware): elfutils - failed test (failure) (master)
A new failure has been detected on builder elfutils-centos-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/39/builds/164 Build state: failed test (failure) Revision: e24d8a4a3ea106608bb3e8d33c4639cf71d0f08d Worker: centos-x86_64 Build Reason: (unknown) Blamelist: Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/6/logs/stdio - warnings (2): https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/6/logs/warnings__2_ - 7: make check ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/164/steps/18/logs/stdio
☺ Buildbot (Sourceware): elfutils - build successful (master)
A restored build has been detected on builder elfutils-centos-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/39/builds/165 Build state: build successful Revision: e24d8a4a3ea106608bb3e8d33c4639cf71d0f08d Worker: centos-x86_64 Build Reason: (unknown) Blamelist: Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/6/logs/stdio - warnings (2): https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/6/logs/warnings__2_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/165/steps/18/logs/stdio
Re: [PATCH v3] strip: keep .ctf section in stripped file
Hi Nick, On Tue, 2023-02-28 at 12:59 +, Nick Clifton wrote: > > O, this surprises me. I wasn't aware binutils strip keeps unallocated > > sections by default. But apparently it does. It doesn't seem specific > > to ".ctf". Do you know why? This seems counter to how strip is supposed > > to behave, at least how I understand it. > > Actually thinking about it, there are a few important un-allocated sections > that ought to be kept in a binary. For example .gnu_debuglink and .shstrtab. > So maybe deleting unallocated sections by default is not such a good idea. Sure, but both are those are actually added or rewritten during stripping. There are some exceptions to the general rule in eu-strip of dropping not referenced, non-allocated, SHT_PROGBIT sections. SHT_NOTE sections are never removed (even if they aren't allocated), as are non- SHT_PROGBIT sections. ".gnu.warning." sections also aren't (even if they are non-allocated SHT_PROGBIT sections). And ".comment" sections aren't if not explicitly told to. Guillermo's patch proposes to make ".ctf" another special case (defaulting to keeping). I am mainly wondering why binutils strip already seems to keep ".ctf" sections (even without -g). Cheers, Mark
[Bug debuginfod/29472] Support querying the debuginfod-server for metadata
https://sourceware.org/bugzilla/show_bug.cgi?id=29472 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #5 from Mark Wielaard --- Followup patch: https://patchwork.sourceware.org/project/elfutils/patch/20221101142306.gl16...@redhat.com/ -- You are receiving this mail because: You are on the CC list for the bug.
