Reported against the Fedora valgrind package. valgrind /usr/bin/Xvfb :10 ==7018== Memcheck, a memory error detector ==7018== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7018== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==7018== Command: ./build/hw/vfb/Xvfb :10 ==7018== ==7018== Valgrind: debuginfo reader: ensure_valid failed: ==7018== Valgrind: during call to ML_(img_get) ==7018== Valgrind: request for range [460632, +12) exceeds ==7018== Valgrind: valid image size of 333064 for image: ==7018== Valgrind: "/usr/lib/debug/.build-id/3e/30f2307639da3a66b4c72c310049c659461253.debug" ==7018== ==7018== Valgrind: debuginfo reader: Possibly corrupted debuginfo file. ==7018== Valgrind: I can't recover. Giving up. Sorry. ==7018== The issue is triggered when trying to read the build-id from a .debug file through the phdrs. The phdrs in a .debug file might not be valid (they are a copy of the main ELF file) and so even if a build-id is found it might be invalid (but we might not know). We really shouldn't even try. This patch fixes the issue: diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c index 70c28e629..8bd3e049c 100644 --- a/coregrind/m_debuginfo/readelf.c +++ b/coregrind/m_debuginfo/readelf.c @@ -1137,7 +1137,11 @@ HChar* find_buildid(DiImage* img, Bool rel_ok, Bool search_shdrs) ElfXX_Ehdr ehdr; ML_(img_get)(&ehdr, img, 0, sizeof(ehdr)); - for (i = 0; i < ehdr.e_phnum; i++) { + /* Skip the phdrs when we have to search the shdrs. In separate + .debug files the phdrs might not be valid (they are a copy of + the main ELF file) and might trigger assertions when getting + image notes based on them. */ + for (i = 0; !search_shdrs && i < ehdr.e_phnum; i++) { ElfXX_Phdr phdr; ML_(img_get)(&phdr, img, ehdr.e_phoff + i * ehdr.e_phentsize, sizeof(phdr));
commit f1f543a224eec5afd8cfddea70c1307ed0a20c55 Author: Mark Wielaard <mark@klomp.org> Date: Mon Apr 16 16:53:56 2018 +0200 Don't read build-id ELF Note in .debug file through phdrs. Bug #393062 - Reading build-id ELF note through phdrs triggers "debuginfo reader: ensure_valid failed" Skip the phdrs when we have to search the shdrs. In separate .debug files the phdrs might not be valid (they are a copy of the main ELF file) and might trigger assertions when getting image notes based on them.
Created attachment 153823 [details] Valgrind: during call to ML_(img_get_UChar) I met a problem when I use valgrind(3.19, 3.20) /oemdata/jmcotards # valgrind --tool=memcheck /mnt/ext_sdcard/valgrind/lib/ld-li nux.so.3 ./masterda ==20694== Memcheck, a memory error detector ==20694== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==20694== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==20694== Command: /mnt/ext_sdcard/valgrind/lib/ld-linux.so.3 ./masterda ==20694== ==20694== Valgrind: debuginfo reader: ensure_valid failed: ==20694== Valgrind: during call to ML_(img_get_UChar) ==20694== Valgrind: request for range [3555828, +1) exceeds ==20694== Valgrind: valid image size of 38868 for image: ==20694== Valgrind: "/mnt/ext_sdcard/valgrind/lib/ld-2.22.so" ==20694== ==20694== Valgrind: debuginfo reader: Possibly corrupted debuginfo file. ==20694== Valgrind: I can't recover. Giving up. Sorry. ==20694==
(In reply to willzhang121@foxmail.com from comment #2) > Created attachment 153823 [details] > Valgrind: during call to ML_(img_get_UChar) > > I met a problem when I use valgrind(3.19, 3.20) Which platform is this?
The original issue was fixed by: commit f1f543a224eec5afd8cfddea70c1307ed0a20c55 Author: Mark Wielaard <mark@klomp.org> Date: Mon Apr 16 16:53:56 2018 +0200 Don't read build-id ELF Note in .debug file through phdrs. Bug #393062 - Reading build-id ELF note through phdrs triggers "debuginfo reader: ensure_valid failed" Skip the phdrs when we have to search the shdrs. In separate .debug files the phdrs might not be valid (they are a copy of the main ELF file) and might trigger assertions when getting image notes based on them. The report in comment #2 seems unrelated and there has been no follow-up on questions about platform.