Hi,
In dwfl_segment_report_module.c:657ff we have this heuristic to determine if an
elf is invalid:
if ((module_end > module->start && module_start < module->end)
|| dyn_vaddr == module->l_ld)
{
if (module->elf != NULL
&& invalid_elf (module->elf, module->disk_file_has_build_id,
build_id, build_id_len))
{
elf_end (module->elf);
close (module->fd);
module->elf = NULL;
[...]
As far as I understand, module_start, module_end, module->start and module->end
are the runtime mmap'd positions of the loaded elf file. The problem with this
is that multiple elfs can be mmap'd on top of one another. That frequently
happens. For example ld.so is always overwritten at some point. If we retrieve
the positions of the overwritten mmaps from e.g. a core file, then we can
attribute them to the wrong elf file, find that the build ID is "wrong" and
discard the elf. This makes the run-backtrace-native-core.sh test fail for me
in sometimes. linux-vdso.so is apparently mapped underneath backtrace-child and
consequently backtrace-child gets discarded. Then we cannot unwind anything.
regards,
Ulf
