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