|
From: <rg...@sd...> - 2004-01-22 22:32:22
|
I get an error when running valgrind under certain circumstances on my machine. If I log in at the console as user "test" (a user with the default environment and dotfiles I set up when narrowing this down) and run "valgrind ls" it works fine and gives the expected output. If I ssh to localhost and log in that way it works too. However, if I log in as that user via "su - test" then it gives an odd error. This is an issue for me because valgrind gives the same error when I am logged in as my usual user, using the special dotfiles and environment I have set up for development. I am trying to track the issue down because I need to modify whatever is breaking valgrind in my development environment. This is a Debian testing machine, using the valgrind that comes from installing with apt-get. However, I have replicated most of these problems with installations of the most recent stable and development sources. Here's what valgrind does when it works: est@rgristroph-austin:~$ /usr/bin/valgrind.bin ls ==4363== Memcheck, a memory error detector for x86-linux. ==4363== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==4363== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==4363== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==4363== Estimated CPU clock rate is 560 MHz ==4363== For more details, rerun with: -v ==4363== env-login env.su v-broke.log v-work.log ==4363== ==4363== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==4363== malloc/free: in use at exit: 13932 bytes in 38 blocks. ==4363== malloc/free: 43 allocs, 5 frees, 18126 bytes allocated. ==4363== For a detailed leak analysis, rerun with: --leak-check=yes ==4363== For counts of detected errors, rerun with: -v test@rgristroph-austin:~$ Here's what the output is when it doesn't work: test@rgristroph-austin:~$ /usr/bin/valgrind.bin ls ==4357== valgrind: failed to move logfile fd into safe range ==4357== Memcheck, a memory error detector for x86-linux. ==4357== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==4357== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==4357== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. valgrind: vg_mylibc.c:1153 (vgPlain_safe_fd): Assertion `newfd > (1024 - (100*2 + 4))' failed. ==4357== at 0x40177FCD: ??? ==4357== by 0x40177FCC: ??? ==4357== by 0x4017805B: ??? ==4357== by 0x401781AA: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==4357== at 0x4017FEA0: ??? ==4357== by 0x4000C0CD: ??? ==4357== by 0x4000C269: ??? ==4357== by 0x40000C3C: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. test@rgristroph-austin:~$ Naturally the first thing I did was compare the two environments. I did prinenv and redirected it to a file in each window, and then I diff'd those two files. The results were not very informative: test@rgristroph-austin:~$ diff env.su env-login 1,2d0 < HZ=100 < SHELL=/bin/bash 3a2,4 > SHELL=/bin/bash > SSH_CLIENT=127.0.0.1 2103 22 > SSH_TTY=/dev/pts/7 10a12,13 > SSH_CONNECTION=127.0.0.1 2103 127.0.0.1 22 > DISPLAY=localhost:10.0 test@rgristroph-austin:~$ Nothing seemed amiss there. I tried manually unsetting that $HZ variable to make the two environments more similar, but the error still happened. Next, I ran this command in the login that worked: strace -o v-work.log /usr/bin/valgrind.bin ls and this command in the login that didn't work: strace -o v-broke.log /usr/bin/valgrind.bin ls which resulted in two log files of the system calls for the working and non-working runs. I thought those were a bit big to simply post to the list, so I put them here: http://rgr.freeshell.org/v-work.log http://rgr.freeshell.org/v-broke.log http://rgr.freeshell.org/valgrind-problems.html Unfortunately I can't see what is causing the problems from those logs. Everything seems nearly exactly the same and then one prints out and error and the other starts running ls. Maybe someone has seen this behaviour before ? Or maybe someone more familar with how valgrind works could make more sense out of the strace logs ? I am willing to take the latest valgrind and run it in gdb in each environment if necessary. If I do that is there any tricks or advice on setting break points and so on ? Thanks in advance for any help you can offer ! --Rob |
|
From: Jeremy F. <je...@go...> - 2004-01-22 22:45:51
|
On Thu, 2004-01-22 at 14:32, Rob Ristroph wrote: > I am willing to take the latest valgrind and run it in gdb in each environment > if necessary. If I do that is there any tricks or advice on setting > break points and so on ? What does ulimit -n say in each case? Have you tried CVS HEAD? J |
|
From: <rg...@sd...> - 2004-01-23 00:04:12
|
>>>>> "Jeremy" == Jeremy Fitzhardinge <je...@go...> writes: Jeremy> Jeremy> On Thu, 2004-01-22 at 14:32, Rob Ristroph wrote: >> I am willing to take the latest valgrind and run it in gdb in each environment >> if necessary. If I do that is there any tricks or advice on setting >> break points and so on ? Jeremy> Jeremy> What does ulimit -n say in each case? Have you tried CVS HEAD? Jeremy> Jeremy> J ulimit -n gave 256 in one case and 1024 in another. I have fixed my problem -- you cannot believe how relieved this makes me, as valgrind is very important to solving some persistent problems I'm having. You have my complete appreciation and thanks. I haven't tried it with the CVS HEAD or even any of the other versions yet. Thanks again, this is great. --Rob |
|
From: Tom H. <th...@cy...> - 2004-01-23 00:11:07
|
In message <874...@rg...>
rg...@sd... (Rob Ristroph) wrote:
> ulimit -n gave 256 in one case and 1024 in another. I have fixed my
> problem -- you cannot believe how relieved this makes me, as valgrind
> is very important to solving some persistent problems I'm having. You
> have my complete appreciation and thanks.
>
> I haven't tried it with the CVS HEAD or even any of the other versions
> yet.
You should find that it works with the CVS head as that version now
automatically adjusts the limit at startup, and will cope with a lower
limit even if it can't adjust it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|