Just compiled valgrind 3.0.0. Doesn't do much. Here's sample output: $ valgrind -v ls ==793== Memcheck, a memory error detector. ==793== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==793== Using LibVEX rev 1313, a library for dynamic binary translation. ==793== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==793== Using valgrind-3.0.0, a dynamic binary instrumentation framework. ==793== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. --793-- Valgrind library directory: /usr/lib/valgrind --793-- Command line --793-- ls --793-- Startup, with flags: --793-- -v --793-- Contents of /proc/version: --793-- Linux version 2.6.12-gentoo-r7 (root@kelnos.spuriousinterrupt.org) (gc c version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)) #1 Mon Aug 1 00:16:38 PDT 2005 --793-- Reading syms from /bin/ls (0x8048000) --793-- object doesn't have a symbol table --793-- Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) --793-- Reading syms from /usr/lib/valgrind/stage2 (0xB0000000) --793-- object doesn't have a symbol table --793-- Reading suppressions file: /usr/lib/valgrind/default.supp ==793== ==793== ==793== Process terminating with default action of signal 4 (SIGILL): dumping co re ==793== Illegal operand at address 0xB00474E0 ==793== at 0x1B8E47D0: (within /lib/ld-2.3.5.so) ==793== ==793== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==793== malloc/free: in use at exit: 0 bytes in 0 blocks. ==793== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==793== ==793== No malloc'd blocks -- no leaks are possible. --793-- memcheck: sanity checks: 0 cheap, 1 expensive --793-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --793-- memcheck: auxmaps: 0 searches, 0 comparisons --793-- memcheck: secondaries: 6 issued (384k, 0M) --793-- memcheck: secondaries: 0 accessible and distinguished (0k, 0M) --793-- tt/tc: 0 tt lookups requiring 0 probes --793-- tt/tc: 0 fast-cache updates, 1 flushes --793-- translate: new 0 (0 -> 0; ratio 0:10) [0 scs] --793-- translate: dumped 0 (0 -> ??) --793-- translate: discarded 0 (0 -> ??) --793-- scheduler: 0 jumps (bb entries). --793-- scheduler: 0/1 major/minor sched events. --793-- sanity: 1 cheap, 1 expensive checks. --793-- exectx: 4999 lists, 0 contexts (avg 0 per list) --793-- exectx: 0 searches, 0 full compares (0 per 1000) --793-- exectx: 0 cmp2, 0 cmp4, 0 cmpAll Illegal instruction (core dumped) This happens with any binary I try. I added RESTRICT=nostrip to the ebuild, but the backtrace was still useless. $ sudo emerge --info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.1 2-gentoo-r7 i686) ================================================================= System uname: 2.6.12-gentoo-r7 i686 AMD Athlon(tm) processor Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disable d] ccache version 2.2 [disabled] dev-lang/python: 2.2.3-r5, 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/ 3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdow n /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/sh are/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /va r/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-tbird -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo ftp://ftp.ussg.iu.edu /pub/linux/gentoo http://gentoo.osuosl.org/ http://gentoo.ccccom.com" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X aalib acpi4linux alsa apache2 apm audiofile avi berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl dmx dvd dvdr dvdread eds embo ss encode fam fbcon ffmpeg flac flash foomaticdb fortran gd gdbm gif glibc-compa t20 gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib inherit -graph innodb ipv6 jack java joystick jpeg junit kerberos krb4 ldap libcaca libg ++ libwww lirc mad matroska mbox mikmod mmx mmxext mp3 mpeg music mysql ncurses nls nptl nptlonly nvidia ogg oggvorbis opengl oss pam pdflib perl pic png python qt quicktime readline remix rtc samba sasl sdl session slang speex spell sqlite sse ssl stencil-buffer subversion svg svga tcltk tcpd tetex theora tiff truetyp e truetype-fonts type1-fonts ungif usb v4l2 voice vorbis win32codecs wmf xchatte xt xfs xine xml xml2 xv xvid xvmc zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Are you using the hardened gcc profile? If so, try building your app without it and see what happens. Also try building valgrind without it.
No, I'm using: $ ls -ld /etc/make.profile lrwxrwxrwx 1 root root 48 Apr 11 00:53 /etc/make.profile -> ../usr/portage/profiles/default-linux/x86/2005.0/
Actually i was asking for the output of gcc-config -l. Sorry if I wasn't clear.
Yeah, that would make more sense ^_^. Here you go: $ gcc-config -l [1] i686-pc-linux-gnu-3.3.4 [2] i686-pc-linux-gnu-3.4.4 * [3] i686-pc-linux-gnu-3.4.4-hardened [4] i686-pc-linux-gnu-3.4.4-hardenednopie [5] i686-pc-linux-gnu-3.4.4-hardenednopiessp [6] i686-pc-linux-gnu-3.4.4-hardenednossp
Could you try disabling the following line in the ebuild, rebuild valgrind and see if it fixes things? myconf="${myconf} --enable-pie"
Seems like your cpu does not support SSE (though you have 'sse' USE flag). http://bugs.kde.org/show_bug.cgi?id=110274
Looks like Serge is right. Brian, what does /proc/cpuinfo tell you?
Well, I feel like an idiot. No, my CPU doesn't have SSE support (Athlon Thunderbird). I'm not really sure how that USE flag got in there. Perhaps I thought I was putting it there for one of my other machines and got confused which terminal I was in. However, removing 'sse' and recompiling didn't help. Removing the --enable-pie line didn't help either. I'm going to re-emerge system overnight, on the off chance that 'sse' screwed something up. Will report back later.
I might have misinterpreted the valgrind bug-report at kde.org, but I thought it clearly said: <quote> Correct. SSE1 is now a minimum requirement. Supporting non-SSE variants is too much hassle and everybody, more or less, has at least a Pentium-III or equivalent CPU anyway. </quote> So if your CPU doesn't offer SSE, then it won't work - no matter if you have the SSE use flag or not.
as a 2nd note - shouldn't we require the sse USE flag in that case in the ebuild ?
Brian, could you try 2.4.1 instead? I think that one should work without sse.
Bummer. I should have actually read the bug you pointed to instead of just assuming you meant that I had bad USE flags ^_^. That's a shame. I've downgraded to 2.4.1, and it appears to work ok, except that some apps segfault inside it that don't crash outside. Which is annoying, but I'm not sure if that's valgrind's fault or the app's. Anyway, looks like there's no bug here. Sorry for the noise.
I would like to investigate the segfaults you mention. Does removing of --enable-pie fix that? I was already considering disabling it, so if people do experience problems...
I'm gonna change the status a bit, so I can keep better track of this problem. I can tell you at least that this problem will be fixed in the next valgrind release, but I'm waiting to see how long it takes before that release comes out. If it takes too long, I'll add a patch to the current ebuild.
Postponing.
(In reply to comment #13) > I would like to investigate the segfaults you mention. > Does removing of --enable-pie fix that? > I was already considering disabling it, so if people do experience problems... No, it doesn't. Interestingly, in both apps, the crashes occur deep in dlopen() calls (both apps use glib's gmodule interface). Though the crash appears to occur when gdk-pixbuf dlopen()s its image loaders, not in the app's own usage of gmodule. Here's a sample stacktrace; probably won't be useful, but who knows: #0 0x1d2c456e in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 #1 0x1d2c4348 in call_initialize_minimal () from /lib/libpthread.so.0 #2 0x1d2c3ef8 in _init () from /lib/libpthread.so.0 #3 0x1b8ef864 in call_init () from /lib/ld-linux.so.2 #4 0x1b8ef9b0 in _dl_init_internal () from /lib/ld-linux.so.2 #5 0x1c03735e in getutmpx () from /lib/libc.so.6 #6 0x1b8ef6b0 in _dl_catch_error () from /lib/ld-linux.so.2 #7 0x1c0379c8 in _dl_open () from /lib/libc.so.6 #8 0x1bd81d08 in ?? () from /lib/libdl.so.2 #9 0xfffffffe in ?? () #10 0x1c32b369 in ?? () #11 0x1c299eb0 in ?? () #12 0x1b8f9fd4 in ?? () from /lib/ld-linux.so.2 #13 0x1b8f9ca0 in ?? () from /lib/ld-linux.so.2 #14 0x00000002 in ?? () #15 0x52bfb4f8 in ?? () #16 0x1b8ef6b0 in _dl_catch_error () from /lib/ld-linux.so.2 #17 0x1b8ef6b0 in _dl_catch_error () from /lib/ld-linux.so.2 #18 0x1bd822dd in dlerror () from /lib/libdl.so.2 #19 0x1bd81d61 in dlopen () from /lib/libdl.so.2 #20 0x1bd7e473 in g_module_open () from /usr/lib/libgmodule-2.0.so.0 #21 0x1bcfbfe3 in gdk_pixbuf_new_from_data () from /usr/lib/libgdk_pixbuf-2.0.so.0 #22 0x1bcfc70f in gdk_pixbuf_new_from_file () from /usr/lib/libgdk_pixbuf-2.0.so.0 #23 0x1b946e7f in xfce_icon_theme_load (icon_theme=0x1ca290d8, icon_name=0x1c26b678 "xfce4-backdrop", icon_size=16) at xfce-icontheme.c:942 #24 0x1c3edc5c in menu_file_xml_start (context=0x1c26b4b0, element_name=0x1c26b348 "title", attribute_names=0x1c26b8e0, attribute_values=0x1c26b570, user_data=0x52bfd120, error=0x52bfd090) at desktop-menu-file.c:400 #25 0x1bef8b73 in g_markup_parse_context_parse () from /usr/lib/libglib-2.0.so.0 #26 0x1c3ec7b6 in desktop_menu_file_parse (desktop_menu=0x1c245060, filename=0x1c2621a0 "/home/brian/.cache/xfce4/desktop/menu-cache--home-brian-.config-xfce4-desktop-menu.xml.xml", menu=0x1c26b4b0, cur_path=0x1c3f3330 "/", is_root=1, from_cache=1) at desktop-menu-file.c:592 #27 0x1c3ea6a6 in _generate_menu (desktop_menu=0x1c245060, force=0) at desktop-menu.c:120 #28 0x1c3ea767 in _generate_menu_initial (data=0x1c245060) at desktop-menu.c:211 #29 0x1bef64c1 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0 #30 0x1bef332d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #31 0x1bef4c77 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0 #32 0x1bef4faa in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #33 0x1ba9e083 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #34 0x0804daad in main (argc=1, argv=0x52bfdc74) at main.c:308
A few more things to try: - does it crash when run from gdb? - does an strace show anything useful? What application is this? Maybe I can reproduce the problem.
It's xfdesktop from our SVN trunk (http://xfce.org/~kelnos/xfce-snapshots/). Might be a little work to get the deps compiled... though it may run against the libs from 4.2.2. Although, the new problem may be in the libs...
By the way, xfce4-panel also exhibits the same problem, and crashes with pretty much the same backtrace.
Brian, I just added valgrind 3.0.1 to portage. It should no longer require SSE. Could you verify that it works for you? And while you're at it, if you still experience the second problem with this version, could you please submit a separate bugreport for it? That will allow me to close this one when appropriate.
Unfortunately, not really. It doesn't die with SIGILL anymore, but sometimes valgrind dies almost immediately with: vex: priv/host-x86/hdefs.c:2315 (emit_X86Instr): Assertion `0' failed. vex storage: P 512, T total 581077868 (18419203), T curr 18684 (653) valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==19522== at 0xB00171E7: (within /usr/lib/valgrind/stage2) ==19522== by 0xB00171E6: (within /usr/lib/valgrind/stage2) ==19522== by 0xB001721F: vgPlain_core_panic_at (in /usr/lib/valgrind/stage2) ==19522== by 0xB0017248: vgPlain_core_panic (in /usr/lib/valgrind/stage2) ==19522== by 0xB00268F6: (within /usr/lib/valgrind/stage2) ==19522== by 0xB006A264: vex_assert_fail (in /usr/lib/valgrind/stage2) ==19522== by 0xB006F471: emit_X86Instr (in /usr/lib/valgrind/stage2) ==19522== by 0xB0069EB7: LibVEX_Translate (in /usr/lib/valgrind/stage2) ==19522== by 0xB0026E77: vgPlain_translate (in /usr/lib/valgrind/stage2) ==19522== by 0xB003EEEF: vgPlain_scheduler (in /usr/lib/valgrind/stage2) ==19522== by 0xB005FA74: vgModuleLocal_thread_wrapper (in /usr/lib/valgrind/stage2) ==19522== by 0xB005AA32: (within /usr/lib/valgrind/stage2) This doesn't happen with all apps. 'ls' seem to run ok, but the ones I'm actually interested in profiling right now (xfdesktop and xfmedia) fail like this. 'gcalctool' also causes the above failure.
How do you feel about modifying valgrind to try something out? If you're up for it, try what is described in this bug report: http://bugs.kde.org/show_bug.cgi?id=112167 Otherwise I'll create a patch that you can add to the ebuild.
Yep, commenting out that assert statement seems to do the trick.
Updating resolution
This should no longer be a problem.
