Hi, On 2018-07-09 13:34:44 -0700, Andres Freund wrote: > after upgrading binutils (from 2.30-22 to 2.30.90.20180705-1) *newly* > built binaries don't work well with valgrind anymore. Binaries built > with an older version of binutils, verified by downgrading, continue > to work well with valgrind. > > The stack traces after the upgrade are useless. This both makes using > valgrind nearly pointless, as well as breaking valgrind suppression > files (which rely on useful backtraces). > > A trivial example is the following: > > $ dpkg-query --showformat='${Version}' --show binutils > 2.30-22 > > $ cat ~/tmp/uninitialized.c > int > main(int argc, char **argv) > { > int foo; > > if (foo == 3) > return 0; > else > return 1; > } > > $ gcc ~/tmp/uninitialized.c -o uninitialized > $ valgrind ./uninitialized > ... > ==16745== Conditional jump or move depends on uninitialised value(s) > ==16745== at 0x108609: main (in /home/andres/tmp/uninitialized) > .. > > # dpkg -i *binutils*2.30.90* > > $ dpkg-query --showformat='${Version}\n' --show binutils > 2.30.90.20180627-1 > > $ gcc ~/tmp/uninitialized.c -o uninitialized > ... > ==18603== Conditional jump or move depends on uninitialised value(s) > ==18603== at 0x109159: ??? (in /home/andres/tmp/uninitialized) > ==18603== by 0x4CADB16: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) > ... > > but if I force gold to be used: > $ gcc -fuse-ld=gold ~/tmp/uninitialized.c -o uninitialized > $ valgrind ./uninitialized > .... > ==18665== Conditional jump or move depends on uninitialised value(s) > ==18665== at 0x108619: main (in /home/andres/tmp/uninitialized) > > so this seems somewhat likely to be related to GNU ld changes, rather > than a valgrind issue. I haven't yet figured out which of the changes > between the two versions is to blame
Appears to be an issue in valgrind: https://bugs.kde.org/show_bug.cgi?id=395682#c9 I'll try to reassign the bug to valgrind. Greetings, Andres Freund