Summary: | valgrind-3.1.1 fails to start: Killed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin Gramatke <xmit> |
Component: | Current packages | Assignee: | Maurice van der Pot (RETIRED) <griffon26> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bulliver, derk.tebokkel, wakko |
Priority: | High | ||
Version: | 2005.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Valgrind ebuild.
Patch for kernel memory split problem. |
Description
Martin Gramatke
2006-04-03 12:51:21 UTC
Well, we really can't guess :) Reopen with strace, please... http://www.gentoo.org/doc/en/bugzilla-howto.xml#doc_chap3 I'm having the same problem (also calgrind fails to emerge because of this see Bug # 11007 too) valgrind 3.1.1 So here is the strace info::: sudo strace -ovalgrind-fail.log valgrind /usr/bin/ls derk@zwift ~ $ cat valgrind-fail.log execve("/usr/bin/valgrind", ["valgrind", "/usr/bin/ls"], [/* 71 vars */]) = 0 brk(0) = 0x804d000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=170965, ...}) = 0 mmap2(NULL, 170965, PROT_READ, MAP_PRIVATE, 3, 0) = 0xa7fb9000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1192464, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa7fb8000 mmap2(NULL, 1164668, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xa7e9b000 mmap2(0xa7fb1000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x115) = 0xa7fb1000 mmap2(0xa7fb5000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa7fb5000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa7e9a000 set_thread_area({entry_number:-1 -> 6, base_addr:0xa7e9a6b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xa7fb1000, 8192, PROT_READ) = 0 mprotect(0xa7ffc000, 4096, PROT_READ) = 0 munmap(0xa7fb9000, 170965) = 0 open("/usr/bin/ls", O_RDONLY) = 3 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0xa7fe2000 close(3) = 0 munmap(0xa7fe2000, 4096) = 0 readlink("/proc/self/exe", "/usr/bin/valgrind", 4096) = 17 brk(0) = 0x804d000 brk(0x806e000) = 0x806e000 execve("/usr/lib/valgrind/x86-linux/memcheck", ["valgrind", "/usr/bin/ls"], [/* 72 vars */]) = 0 +++ killed by SIGKILL +++ My emerge info in case it is different. emerge --info Portage 2.1_pre7-r4 (default-linux/x86/2005.1, gcc-4.1.0, glibc-2.4-r1, 2.6.16-gentoo-r1 i686) ================================================================= System uname: 2.6.16-gentoo-r1 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.12.0_pre16 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5-r2, 2.4.2-r1 sys-apps/sandbox: 1.2.17 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-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.16 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-mtune=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openjms/config /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-mtune=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig cvs distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/bigdisk1/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac aalib accessibility acpi alsa amarok amr amrr apm arts asf audiofile avi berkdb bitmap-fonts bonobo bzip2 cdr cracklib crypt css cups curl curlwrappers dbus dri dvd dvdr dvdread eds emboss encode esd exif expat flac foomaticdb fortran gdbm gif gimp gimpprint glx gnome gnome-print gnutls gphoto2 gpm grammar gstreamer gtk gtk2 gtkhtml guile hal idn imlib ipv6 isdnlog jack java javascript jpeg jpeg2k kde ladcca ladspa libcaca libg++ libgda libwww lm_sensors mad math mbox mikmod motif mozilla mp3 mp4live mpd-mad mpeg mpeg2 nas ncurses new-login nls nptl nptlonly nsplugin odbc ofx ogg oggvorbis opengl oss pam pcre pdf pdflib perl player png ppds pppd python qt quicktime readline real samba scanner sdl slang sox speex spell sql sqlite sqlite3 ssl svga swat sysfs tcltk tcpd tetex theora thesaurus threads tiff truetype truetype-fonts type1-fonts udev usb v4l v4l2 video_cards_ati video_cards_nv video_cards_nvidia vorbis win32codecs wma wma123 wmf wordperfect xine xml2 xmms xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_wacom kernel_linux userland_GNU video_cards_fbdev video_cards_dummy video_cards_vga video_cards_i810 video_cards_via video_cards_sis video_cards_vesa video_cards_v4l video_cards_vmware" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS Just a thought is this problem peculiar to glibc-2.4 users? I notice both of the emerge info's indicate glibc-2.4 usage. # strace -ostrace.log valgrind --version # cat strace.log execve("/usr/bin/valgrind", ["valgrind", "--version"], [/* 50 vars */]) = 0 brk(0) = 0x804d000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6ff12000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=120383, ...}) = 0 mmap2(NULL, 120383, PROT_READ, MAP_PRIVATE, 3, 0) = 0x6fef4000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1222300, ...}) = 0 mmap2(NULL, 1160828, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x6fdd8000 mmap2(0x6feed000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x114) = 0x6feed000 mmap2(0x6fef1000, 9852, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x6fef1000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6fdd7000 set_thread_area({entry_number:-1 -> 6, base_addr:0x6fdd76b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x6feed000, 8192, PROT_READ) = 0 mprotect(0x6ff2c000, 4096, PROT_READ) = 0 munmap(0x6fef4000, 120383) = 0 readlink("/proc/self/exe", "/usr/bin/valgrind", 4096) = 17 brk(0) = 0x804d000 brk(0x806e000) = 0x806e000 execve("/usr/lib/valgrind/x86-linux/memcheck", ["valgrind", "--version"], [/* 51 vars */]) = 0 +++ killed by SIGKILL +++ This problem is known upstream, see here: http://bugs.kde.org/show_bug.cgi?id=117290 Do you both happen to have CONFIG_VMSPLIT_3G_OPT=y in your kernel configuration? This is the option: 3G/1G user/kernel split (for full 1G low memory) No. # grep CONFIG_VMSPLIT /usr/src/linux-2.6.16.1/.config # CONFIG_VMSPLIT_3G is not set # CONFIG_VMSPLIT_3G_OPT is not set CONFIG_VMSPLIT_2G=y # CONFIG_VMSPLIT_1G is not set I do have this set ..should I unset it and try again? grep CONFIG_VMSPLIT /usr/src/linux-2.6.16-gentoo-r1/.config # CONFIG_VMSPLIT_3G is not set CONFIG_VMSPLIT_3G_OPT=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set Actually I have two machines both with the same option set. On one valgrind works works on the other valgrind does not work?!!? So I decided to look at what was different on the two machines. It seems to amount to this the machine on which valgrind does run has the kernel compiled by gcc-3.4.6 the one where it does not work has the kernel compiled by gcc-4.1.0. I don't know enough about valgrind but copying the executable over from one machine to another results in the compiled version (a local personal directory copy) from the machine that does not work running on the the machine where valgrind does run. And vica versa the a copy from the working machine fails on the non-working machine so it is not the executable but the kernel compiler which seems to be the part of the problem .. or is it other libraries as the copies call the libraries on the machine where they run. Does this make any sense, or Am I whistling into the wind? further digging reveals that copying /usr/lib/valgrind/x86-linux/memcheck back and forth follows the same pattern ( as memcheck is the actual executable that is failing or working on each machine respectively .. and follows the same pattern) definative result .. I rebooted the non-working valgrind machine into an older gcc-3.4.5 comipled kernel (gentoo-sources-2.6.15-r6) and valgrind works(without a recompile it just runs) also the update to callgrind then compiles obviously. So something wierd is happening in memory management with a gcc-4-1.0 compiled kernel which does not allow valgrind to run !!!!???? Any thoughts anyone? # gcc --version gcc (GCC) 3.4.6 (Gentoo 3.4.6, ssp-3.4.5-1.0, pie-8.7.9) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # valgrind Killed I never had gcc4 but valgrind does not work Derk, it looks like it's the kernel version, not the gcc version. I'll install a 2.6.16 kernel when I get the chance to see if I can narrow it down to a patch. Currently I'm running 2.6.16-rc1, which runs valgrind just fine. Don't know about that ... I've two gcc 3.4.6 compiled kernels (on different machines but all athlon-xp/686) one that works and one that does not .. same kernel version .. gentoo-sources-2.6.16-r1 same kernel version is as the non-working gcc-4.1.0 compiled kernel machine I'm a bit out of my depth here but this seems very quirky. I'm short of time at the moment but I'll try a few other kernel/gcc compile versions once i do have some time. It really is the VMSPLIT kernel patch. As long as you keep it on 3G/1G user/kernel split (the way it used to be), there is no problem. I'll keep an eye on what upstream is going to do, but for now at least there is a workaround. agreed that the work around works but .. it's irritating that this kernel feature can not be used if you want valgrind to work .. does not appear to effect anything else or are other apps also effected? In case anyone is interested, I have a simple fix for the problem. Simply edit valgrind's configure.in (or configure if you like) and look for the lines that have: valt_load_address_normal="0xb0000000" valt_load_address_inner="0xa0000000" All that's needed is to replace them by valt_load_address_normal="0xa0000000" valt_load_address_inner="0x90000000" and it works again with the "full 1G low memory" option. Be aware that even Julian Seward (one of the authors of valgrind) is not sure that change is not going to break anything else. Created attachment 86486 [details]
Valgrind ebuild.
Especially for lazy people ;) ebuild with patch containing Jean-Marc Valin solution to the problem.
Created attachment 86487 [details, diff]
Patch for kernel memory split problem.
And here's patch itself.
I valgrind SVN trunk (currently valgrind 3.2 RC1) the problem was fixed and I have prepared a little patch SVN --> valgrind-3.1.1. Note: The load_address entries differ from the patch that was posted ealier and are now said to work and not to break anythimg else. --- configure.in 2006-03-15 18:52:41.000000000 +0100 +++ configure.in.patched 2006-06-05 20:44:56.707239280 +0200 @@ -117,8 +117,8 @@ i?86) AC_MSG_RESULT([ok (${host_cpu})]) VG_ARCH="x86" - valt_load_address_normal="0xb0000000" - valt_load_address_inner="0xa0000000" + valt_load_address_normal="0x38000000" + valt_load_address_inner="0x28000000" ;; x86_64) Valgrind 3.2.0 is now in the tree, so that fixes this bug. My thanks to all. *** Bug 110007 has been marked as a duplicate of this bug. *** *** Bug 144270 has been marked as a duplicate of this bug. *** |