FS#19634 - [valgrind] Missing suppressions for glibc 2.12
Attached to Project:
Arch Linux
Opened by Dave Reisner (falconindy) - Friday, 28 May 2010, 21:34 GMT
Last edited by Allan McRae (Allan) - Thursday, 03 June 2010, 13:20 GMT
Opened by Dave Reisner (falconindy) - Friday, 28 May 2010, 21:34 GMT
Last edited by Allan McRae (Allan) - Thursday, 03 June 2010, 13:20 GMT
|
Details
Version: 3.5.0-4
Synopsis: valgrind is incredibly verbose about code that was previously "quiet" in glibc 2.11. To reproduce: compile [1] as follows: gcc noisy.c -lcurl -o noisy Possible resolution: The trunk of the SVN (r11136) compiles cleanly without any patches and behaves as expected (no excessive complaints). I've created valgrind-svn on the AUR [2] as a record of what I've done. [1] http://codepad.org/htorjWF9 [2] http://aur.archlinux.org/packages.php?ID=37594 |
This task depends upon
Closed by Allan McRae (Allan)
Thursday, 03 June 2010, 13:20 GMT
Reason for closing: Fixed
Additional comments about closing: valgrind-3.5.0-6
Thursday, 03 June 2010, 13:20 GMT
Reason for closing: Fixed
Additional comments about closing: valgrind-3.5.0-6
valgrind-svn (r11137) works without problems.
vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x2E 0xF
#==5888== valgrind: Unrecognised instruction at address 0x50cd9a5.
#==5888== Your program just tried to execute an instruction that Valgrind
#==5888== did not recognise. There are two possible reasons for this.
#==5888== 1. Your program has a bug and erroneously jumped to a non-code
#==5888== location. If you are running Memcheck and you just saw a
#==5888== warning about a bad jump, it's probably your program's fault.
#==5888== 2. The instruction is legitimate but Valgrind doesn't handle it,
#==5888== i.e. it's Valgrind's fault. If you think this is the case or
#==5888== you are not sure, please let us know and we'll try to fix it.
#==5888== Either way, Valgrind will now raise a SIGILL signal which will
#==5888== probably kill your program.
#==5888==
#==5888== Process terminating with default action of signal 4 (SIGILL)
#==5888== Illegal opcode at address 0x50CD9A5
#==5888== at 0x50CD9A5: __memset_sse2 (in /lib/libc-2.12.so)
#==5888== by 0x5511916: doProlog (in /usr/lib/libexpat.so.1.5.2)
#==5888== by 0x5512759: prologProcessor (in /usr/lib/libexpat.so.1.5.2)
#==5888== by 0x550948B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
#==5888== by 0x545FD1A: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.4.4)
#==5888== by 0x5455E31: FcInitLoadConfig (in /usr/lib/libfontconfig.so.1.4.4)
#==5888== by 0x5455F4B: FcInitLoadConfigAndFonts (in /usr/lib/libfontconfig.so.1.4.4)
#==5888== by 0x545604C: FcInit (in /usr/lib/libfontconfig.so.1.4.4)
#==5888== by 0x42B9D81: ??? (in /usr/lib/libQtGui.so.4.6.2)
#==5888== by 0x423FCB9: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/libQtGui.so.4.6.2)
#==5888== by 0x42404D2: QApplication::QApplication(int&, char**, int) (in /usr/lib/libQtGui.so.4.6.2)
#==5888== by 0x804E68F: main (main.cpp:6)
r10925 - works
r10912 - fails
edit: that was for the noise issue
@seezer: please file a separate bug, preferably with a simple test case. Even better, find the svn commit that fixes it! :P