On 26.01.26 17:50, Mark Wielaard wrote:
> Hi Hans,
>
> On Sat, 2026-01-24 at 09:35 +0100, Hans wrote:
>> Using the latest eu-unstrip (or an older) on a relatively big core
>> dump (>1G) results in a list with just three buildids
>> (eu-unstrip -n --core prog.core), although gdb lists more than 200
>> shared objects.
>>
>> Extracting the first page of each elf file in the core manually and
>> check with 'readelf -n <page>' reveal each buildid properly.
>>
>> Do you have any ideas why eu-unstrip is not dumping all the buildids
>> in the core dump although they are available in the core dump?
>
> No, sorry I don't immediately know what could cause that.
> How was the core file generated?
>
> Could you show the eu-unstrip -n --core prog.core output and the gdb
> list of shared objects?
>
> Thanks,
>
> Mark
Unfortunately our debian kernel is based on 6.12.18 which has a fixed sorting
of the vmas in dump_vma_snapshot().
https://lore.kernel.org/all/[email protected]/
6.12.19 introduced core_sort_vma to disable sorting.
https://lore.kernel.org/all/[email protected]/
core_sort_vma
The default coredump writes VMAs in address order. By setting core_sort_vma to
1,
VMAs will be written from smallest size to largest size. This is known to break
at least elfutils, but can be handy when dealing with very large (and truncated)
coredumps where the more useful debugging details are included in the smaller
VMAs.
https://docs.kernel.org/admin-guide/sysctl/kernel.html#core-sort-vma
And here:
https://sourceware.org/bugzilla/show_bug.cgi?id=32713
I think, I know now what the problem is.
Thanks for your support.
Hans
