When running wine's 32bit tests under valgrind with debian's debug symbols installed, I get a ton of errors like: --1235044-- WARNING: Serious error when reading debug info --1235044-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9: --1235044-- debuginfo section duplicates a section in the main ELF file --1235044-- WARNING: Serious error when reading debug info --1235044-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlicommon.so.1.0.9: --1235044-- debuginfo section duplicates a section in the main ELF file --1235057-- WARNING: Serious error when reading debug info --1235057-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9: --1235057-- debuginfo section duplicates a section in the main ELF file --1235057-- WARNING: Serious error when reading debug info --1235057-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlicommon.so.1.0.9: --1235057-- debuginfo section duplicates a section in the main ELF file
Created attachment 132554 [details] libbrotlidec.so.1.0.9
Created attachment 132556 [details] .debug files There are a few .debug files listed for this package, so I included all of them.
austin@debian-desktop ~/src/valgrind (master) $ readelf -S /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9 There are 27 section headers, starting at offset 0xc1b0: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .note.gnu.bu[...] NOTE 00000154 000154 000024 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH 00000178 000178 00005c 04 A 3 0 4 [ 3] .dynsym DYNSYM 000001d4 0001d4 0001e0 10 A 4 1 4 [ 4] .dynstr STRTAB 000003b4 0003b4 0002e6 00 A 0 0 1 [ 5] .gnu.version VERSYM 0000069a 00069a 00003c 02 A 3 0 2 [ 6] .gnu.version_r VERNEED 000006d8 0006d8 000040 00 A 4 1 4 [ 7] .rel.dyn REL 00000718 000718 000058 08 A 3 0 4 [ 8] .rel.plt REL 00000770 000770 000058 08 AI 3 21 4 [ 9] .init PROGBITS 00001000 001000 000020 00 AX 0 0 4 [10] .plt PROGBITS 00001020 001020 0000c0 04 AX 0 0 16 [11] .plt.got PROGBITS 000010e0 0010e0 000008 08 AX 0 0 8 [12] .text PROGBITS 000010f0 0010f0 0073f4 00 AX 0 0 16 [13] .fini PROGBITS 000084e4 0084e4 000014 00 AX 0 0 4 [14] .rodata PROGBITS 00009000 009000 001b00 00 A 0 0 32 [15] .eh_frame_hdr PROGBITS 0000ab00 00ab00 0001bc 00 A 0 0 4 [16] .eh_frame PROGBITS 0000acbc 00acbc 000e94 00 A 0 0 4 [17] .init_array INIT_ARRAY 0000cee0 00bee0 000004 04 WA 0 0 4 [18] .fini_array FINI_ARRAY 0000cee4 00bee4 000004 04 WA 0 0 4 [19] .dynamic DYNAMIC 0000cee8 00bee8 0000f8 08 WA 4 0 4 [20] .got PROGBITS 0000cfe0 00bfe0 000020 04 WA 0 0 4 [21] .got.plt PROGBITS 0000d000 00c000 000038 04 WA 0 0 4 [22] .data PROGBITS 0000d038 00c038 000004 00 WA 0 0 4 [23] .bss NOBITS 0000d03c 00c03c 000004 00 WA 0 0 1 [24] .gnu_debugaltlink PROGBITS 00000000 00c03c 000048 00 0 0 1 [25] .gnu_debuglink PROGBITS 00000000 00c084 000034 00 0 0 4 [26] .shstrtab STRTAB 00000000 00c0b8 0000f7 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), p (processor specific) Note that this seems to occur for all/most 32-bit libraries (I see 133 different .so files referenced so far when running the full wine test suite).
Created attachment 133681 [details] armv7l library I also see this with 32-bit arm(v7l): --10058-- WARNING: Serious error when reading debug info --10058-- When reading debug info from /usr/lib/arm-linux-gnueabihf/libbrotlidec.so.1.0.9: --10058-- debuginfo section duplicates a section in the main ELF file austin@arm7:~$ readelf -S /usr/lib/arm-linux-gnueabihf/libbrotlidec.so.1.0.9 There are 25 section headers, starting at offset 0x7208: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .note.gnu.bu[...] NOTE 000000f4 0000f4 000024 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH 00000118 000118 00005c 04 A 3 0 4 [ 3] .dynsym DYNSYM 00000174 000174 000210 10 A 4 3 4 [ 4] .dynstr STRTAB 00000384 000384 0002fb 00 A 0 0 1 [ 5] .gnu.version VERSYM 00000680 000680 000042 02 A 3 0 2 [ 6] .gnu.version_r VERNEED 000006c4 0006c4 000040 00 A 4 2 4 [ 7] .rel.dyn REL 00000704 000704 000060 08 A 3 0 4 [ 8] .rel.plt REL 00000764 000764 000068 08 AI 3 18 4 [ 9] .init PROGBITS 000007cc 0007cc 00000c 00 AX 0 0 4 [10] .plt PROGBITS 000007d8 0007d8 0000b0 04 AX 0 0 4 [11] .text PROGBITS 00000888 000888 004b10 00 AX 0 0 4 [12] .fini PROGBITS 00005398 005398 000008 00 AX 0 0 4 [13] .rodata PROGBITS 000053a0 0053a0 001888 00 A 0 0 4 [14] .eh_frame PROGBITS 00006c28 006c28 000004 00 A 0 0 4 [15] .init_array INIT_ARRAY 00016ef8 006ef8 000004 04 WA 0 0 4 [16] .fini_array FINI_ARRAY 00016efc 006efc 000004 04 WA 0 0 4 [17] .dynamic DYNAMIC 00016f00 006f00 000100 08 WA 4 0 4 [18] .got PROGBITS 00017000 007000 000064 04 WA 0 0 4 [19] .data PROGBITS 00017064 007064 000004 00 WA 0 0 4 [20] .bss NOBITS 00017068 007068 000004 00 WA 0 0 1 [21] .ARM.attributes ARM_ATTRIBUTES 00000000 007068 000031 00 0 0 1 [22] .gnu_debugaltlink PROGBITS 00000000 007099 00004d 00 0 0 1 [23] .gnu_debuglink PROGBITS 00000000 0070e8 000034 00 0 0 4 [24] .shstrtab STRTAB 00000000 00711c 0000ec 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), y (purecode), p (processor specific)
Thanks for including the files, this is really odd the main ELF file has both a .gnu_debuglink section and a .gnu_debugaltlink section, but no .debug sections itself. The .debug file itself also has a .gnu_debugaltlink. (Sidenote, the .gnu_debugaltlink is absolute, instead of a relative path from the .debug file, which makes it slightly harder to find unless you replicate the fill file system layout.) This looks suspiciously like an Ubuntu bug: https://bugs.kde.org/show_bug.cgi?id=396656
(In reply to Mark Wielaard from comment #5) > Thanks for including the files, this is really odd the main ELF file has > both a .gnu_debuglink section and a .gnu_debugaltlink section, but no .debug > sections itself. The .debug file itself also has a .gnu_debugaltlink. > > (Sidenote, the .gnu_debugaltlink is absolute, instead of a relative path > from the .debug file, which makes it slightly harder to find unless you > replicate the fill file system layout.) > > This looks suspiciously like an Ubuntu bug: > https://bugs.kde.org/show_bug.cgi?id=396656 I'm running Debian, not Ubuntu, to be clear, but fair enough. Should I report this to Debian or should I gather some other information first?
(In reply to Austin English from comment #6) > (In reply to Mark Wielaard from comment #5) > > Thanks for including the files, this is really odd the main ELF file has > > both a .gnu_debuglink section and a .gnu_debugaltlink section, but no .debug > > sections itself. The .debug file itself also has a .gnu_debugaltlink. > > > > (Sidenote, the .gnu_debugaltlink is absolute, instead of a relative path > > from the .debug file, which makes it slightly harder to find unless you > > replicate the full file system layout.) > > > > This looks suspiciously like an Ubuntu bug: > > https://bugs.kde.org/show_bug.cgi?id=396656 > > I'm running Debian, not Ubuntu, to be clear, but fair enough. Should I > report this to Debian or should I gather some other information first? I assumed Debian and Ubuntu created the debuginfo packages the same way, but it seems that isn't true. At least not all of the time. It seems the issue in Ubuntu has been occurring for a longer time (since at least 2018), but the issue seems to have only occurred recently Debian packages. Do you happen to know if that observation is correct? And if so, what kind of change in debuginfo package creation might have caused this? In theory valgrind is right to reject a binary that has duplicate .gnu_debugaltlinks in both the main ELF and the separate .debug file. I don't mind working around it, but I have no idea how that can happen or whether we can rely on the .gnu_debugaltlinks being correct. So if you could find/report the issue in Debian and point me at that report, or point them at this report, so we can figure out what is going on, that would be perfect.
So I see both examples are for 32bit Debian packages (i386 and arm32). Is this an 32bit only issue or are you seeing the same for 64bit packages?
commit 8b1961511c93962ea2a9b918af8e9c32e3c24d71 Author: Balint Reczey <balint.reczey@canonical.com> Date: Thu Nov 28 13:34:21 2019 +0100 Don't look for debug alt file in debug image if it is already found With dwz the .gnu_debuglink section may appear duplicated in the debug file referenced originally in the .gnu_debuglink section. https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1848211 https://bugs.kde.org/show_bug.cgi?id=396656 https://bugs.kde.org/show_bug.cgi?id=427969 Signed-off-by: Balint Reczey <balint.reczey@canonical.com>
(In reply to Mark Wielaard from comment #8) > So I see both examples are for 32bit Debian packages (i386 and arm32). Is > this an 32bit only issue or are you seeing the same for 64bit packages? Just tried, I'm not seeing it with 64-bit (though I don't normally run wine's tests under 64-bit, so don't take that as 100% certain). (In reply to Mark Wielaard from comment #9) > commit 8b1961511c93962ea2a9b918af8e9c32e3c24d71 > Author: Balint Reczey <balint.reczey@canonical.com> > Date: Thu Nov 28 13:34:21 2019 +0100 > > Don't look for debug alt file in debug image if it is already found > > With dwz the .gnu_debuglink section may appear duplicated in the > debug file referenced originally in the .gnu_debuglink section. > > https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1848211 > > https://bugs.kde.org/show_bug.cgi?id=396656 > https://bugs.kde.org/show_bug.cgi?id=427969 > > Signed-off-by: Balint Reczey <balint.reczey@canonical.com> Thanks! This works for me on x86 (can't easily test arm at the moment, but will report back if there's a problem there).