Valgrind, an open-source memory debugger

On Mon, Apr 28, 2008 at 12:40 PM, Borse, Ganesh
<ganesh.borse@...> wrote:
> #>./configure --prefix=~/Releases/
>
> configure: error: expected an absolute directory name for --prefix:
> ~/Releases/

Hello Ganesh,

Did you already try the following:

./configure --prefix=$HOME/Releases && make -s && make -s install

You can run this command as an ordinary user, you don't need root
privileges when installing Valgrind in a directory under your
homedirectory.

Bart.

Bart,

I did compile now with this new command.
When I executed the command provided by you, the binaries (& libs) got
installed in my $HOME/Releases/.

Then I copied it over to my production server. There I tried running it
from /home/user2/Releases/bin directory, but it failed as below:

strace valgrind
...
execve("/usr/local/lib/valgrind/x86-linux/memcheck", ["valgrind"], [/*
68 vars */]) = -1 ENOENT (No such file or directory)
write(2, "valgrind: failed to start tool \'"..., 94valgrind: failed to
start tool 'memcheck' for platform 'x86-linux': No such file or
directory

Did I do anything wrong?

I am thinking of doing the build & install Valgrind in 2 steps:
1) Do build on my development machine:
   ./configure --prefix=/home/user2/Releases/valgrind330/ && make -s

2) Do install on production server, like:
   make install

Will this work?

Thanks,
Ganesh

-----Original Message-----
From: Bart Van Assche [mailto:bart.vanassche@...] 
Sent: 28 April 2008 18:50
To: Borse, Ganesh
Cc: valgrind-users@...
Subject: Re: [Valgrind-users] Error while running valgrind on different
machine than orignal place where it was compiled

On Mon, Apr 28, 2008 at 12:40 PM, Borse, Ganesh
<ganesh.borse@...> wrote:
> #>./configure --prefix=~/Releases/
>
> configure: error: expected an absolute directory name for --prefix:
> ~/Releases/

Hello Ganesh,

Did you already try the following:

./configure --prefix=$HOME/Releases && make -s && make -s install

You can run this command as an ordinary user, you don't need root
privileges when installing Valgrind in a directory under your
homedirectory.

Bart.


==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

> I am thinking of doing the build & install Valgrind in 2 steps:
> 1) Do build on my development machine:
>    ./configure --prefix=/home/user2/Releases/valgrind330/ && make -s
>
> 2) Do install on production server, like:
>    make install
>
> Will this work?

I think the only way you can make this work is to build it on your
desktop machine using the --prefix that you need for the production
machine, *and* 'make install' it.  Then copy the install tree to the
exact same location on the production machine.

Even simpler is just to build it directly on the production
machine.

J

Hi,

I could compile Valgrind on one machine & got it installed on another
machine (with few hacks in install target of Makefile).

But, still the "valgrind --tool=memcheck" command looks for the memcheck
binary in /usr/local/lib/valgrind/x86-linux/

As seen in the strace output:
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40132000
set_thread_area({entry_number:-1 -> 6, base_addr:0x401326c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
readlink("/proc/self/exe",
"/app/gce1/Releases/valgrind330/bin/valgrind", 4096) = 43
brk(0)                                  = 0x804d000
brk(0x806e000)                          = 0x806e000
execve("/usr/local/lib/valgrind/x86-linux/memcheck", ["valgrind"], [/*
68 vars */]) = -1 ENOENT (No such file or directory)
write(2, "valgrind: failed to start tool \'"..., 94valgrind: failed to
start tool 'memcheck' for platform 'x86-linux': No such file or
directory
) = 94
exit_group(1)                           = ?


I set the LD_LIBRARY_PATH as well as PATH to point to directory which
has valgrind installed.
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/gce1/Releases/valgrind330/lib/val
grind/x86-linux
export PATH=$PATH:/home/gce1/Releases/valgrind330/lib/valgrind/x86-linux

Is there any way that I can tell valgrind to pick the tools (memcheck,
etc) from directory different than /usr/local/bin? Is there any
environment variable for this?

Thanks,
Ganesh

-----Original Message-----
From: Julian Seward [mailto:jseward@...] 
Sent: 28 April 2008 19:55
To: valgrind-users@...
Cc: Borse, Ganesh
Subject: Re: [Valgrind-users] Error while running valgrind on different
machine than orignal place where it was compiled


> I am thinking of doing the build & install Valgrind in 2 steps:
> 1) Do build on my development machine:
>    ./configure --prefix=/home/user2/Releases/valgrind330/ && make -s
>
> 2) Do install on production server, like:
>    make install
>
> Will this work?

I think the only way you can make this work is to build it on your
desktop machine using the --prefix that you need for the production
machine, *and* 'make install' it.  Then copy the install tree to the
exact same location on the production machine.

Even simpler is just to build it directly on the production
machine.

J



==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

In message <D55964799EE16D49AA715909B72D5C96CA9B53@...>
        Ganesh Borse <ganesh.borse@...> wrote:

> I could compile Valgrind on one machine & got it installed on another
> machine (with few hacks in install target of Makefile).

Look, it was explained yesterday how you should do it... Here is the
step by step version:

On build host:

  # ./configure --prefix=/path/from/root/on/install/host
  # make
  # make install DESTDIR=/tmp/valgrind-root
  # cd /tmp/valgrind-root
  # tar zcvf /tmp/valgrind.tar.gz .
  # scp /tmp/valgrind.tar.gz install-host:/tmp

On install host:

  # cd /
  # tar zxvf /tmp/valgrind.tar.gz
  # /path/from/root/on/install/host/bin/valgrind ...

Tom

-- 
Tom Hughes (tom@...)
http://www.compton.nu/

Dear John
I am not a engineer. The developers of valgrind should look into this. I
assume that they would want to have a complete instruction set in the
product. I have no idea if assembler is a food or a plant. Maybe it would be
easier to contact Intel and do it by the book.
But thanks anyway.
Federico

-----Original Message-----
From: John Reiser [mailto:jreiser@...] 
Sent: Friday, April 25, 2008 12:16 AM
To: Venefax
Cc: valgrind-users@...
Subject: Re: [Valgrind-users] Valgrind does not understand an Opcode

>  "vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0x6F 0x6 0x48
>  0x83

Here's how to start making sense of such a report.  Create a file of
assembler text that has those bytes, compile it, then disassemble it
as instructions:

----- foo.S
.byte 0x48,0xF,0x6F,0x6,0x48,0x83
.byte 0x90,0x90,0x90,0x90  # filler if the report stopped too soon
----- end foo.S

$ gcc -c foo.S
$ gdb foo.o
(gdb) x/i 0
0x0:    rex.W movq   (%rsi),%mm0
(gdb)q

So it's a 64-bit fetch ('q' means "quad": four 16-bit words [8086])
into an MMX register %mm0, and the opcode is modified with a prefix
"rex.W".  So lookup in the CPU reference manual what the prefix
"rex.W" means when applied to a load of an MMX register from memory.

--

On Fri, 25 Apr 2008, Venefax wrote:

> I am not a engineer. The developers of valgrind should look into this. I 
> assume that they would want to have a complete instruction set in the 
> product.

Unfortunately, having a complete instruction set is not as simple as it 
sounds.  x86 and x86-64 have instruction sets that are an enormous, horrible 
mess.  Furthermore, many compilers emit instructions containing undocumented 
combinations of elements and/or redundant elements.  This means that, in 
practice, it isn't clear what "complete instuction set" means.  Julian 
generally adds support for unhandled instructions to Valgrind as they are 
reported.  If you could report the problem in Bugzilla, that would increase 
the chance of it being fixed.

> I have no idea if assembler is a food or a plant. Maybe it would be easier 
> to contact Intel and do it by the book. But thanks anyway.

An assembler translates assembly language to object code.  It's an important 
part of the compilation pipeline and a useful thing for any programmer to 
know about.  See http://en.wikipedia.org/wiki/Assembly_language#Assembler.

Nick

>  "vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0x6F 0x6 0x48
>  0x83

I can fix this, although it would be easier and faster if you had
filed a bug report.

Can you send me the file /usr/lib/asterisk/modules/codec_g723.so to
look at?  bzip2 it first, otherwise my spam filters are likely to block it.

J

On Monday 28 April 2008 13:10, Christian Keil wrote:
> > I had to compile Valgrind source code on a different host because I do
> > not have any compilation tools installed on my production host.
> >
> > I thought of using "-prefix=<Install-dir-path>" while doing
> > "./configure".
> >
> > But I cannot do that also because the directory structure on
> > production
> > host is totally different than development host (this is because user
> > logins are different).
>
> This is the scenario that DESTDIR is made for. Configure Valgrind
> exactly like you would do it when building on your production machine
> (i.e., use the prefix from that machine), make all, and then
>
> $ make install DESTDIR=temporary/install/prefix
>
> This way make will compile the correct paths into the library but copy
> the files to <temporary/install/prefix/...> from where you can just copy
> everything to your production machine.

Sounds good, but do you know if this really works with Valgrind?
I'm sure we "bake in" some paths at build time.

J

On Mon, 2008-04-28 at 13:16 +0200, Julian Seward wrote:
> On Monday 28 April 2008 13:10, Christian Keil wrote:
> > > I had to compile Valgrind source code on a different host because I do
> > > not have any compilation tools installed on my production host.
> > >
> > > I thought of using "-prefix=<Install-dir-path>" while doing
> > > "./configure".
> > >
> > > But I cannot do that also because the directory structure on
> > > production
> > > host is totally different than development host (this is because user
> > > logins are different).
> >
> > This is the scenario that DESTDIR is made for. Configure Valgrind
> > exactly like you would do it when building on your production machine
> > (i.e., use the prefix from that machine), make all, and then
> >
> > $ make install DESTDIR=temporary/install/prefix
> >
> > This way make will compile the correct paths into the library but copy
> > the files to <temporary/install/prefix/...> from where you can just copy
> > everything to your production machine.
> 
> Sounds good, but do you know if this really works with Valgrind?
> I'm sure we "bake in" some paths at build time.

Surely this would be a bug then ;)  As long as the baked in paths are
what was given to configure it should work just fine.  Granted the
install might not work from DESTDIR but once copied to the prefix dir it
should.

Ashley,

In message <200804281316.59549.jseward@...>
        Julian Seward <jseward@...> wrote:

> On Monday 28 April 2008 13:10, Christian Keil wrote:
>
>> This is the scenario that DESTDIR is made for. Configure Valgrind
>> exactly like you would do it when building on your production machine
>> (i.e., use the prefix from that machine), make all, and then
>>
>> $ make install DESTDIR=temporary/install/prefix
>>
>> This way make will compile the correct paths into the library but copy
>> the files to <temporary/install/prefix/...> from where you can just copy
>> everything to your production machine.
>
> Sounds good, but do you know if this really works with Valgrind?
> I'm sure we "bake in" some paths at build time.

It works fine - use it all the time to build RPMs.

Baking in paths is fine - that's the difference between setting the
prefix (which controls the run time path that is baked in) and setting
the DESTDIR at install time which only affects where files are put
so that you can then package them up cleanly.

Tom

-- 
Tom Hughes (tom@...)
http://www.compton.nu/

Am Samstag, 26. April 2008 schrieb Holger Kaelberer:
> Holger Kaelberer wrote on Wed Apr 23, 2008 um 11:46:34AM:
> > I did not find any valgrind-calls/-macros in the code (cf.
> > *talloc*.samba.org). Anyway, I will post at samba-technical.
>
> FYI: No particular problems have been reported by the people
> @samba-technical when using valgrind on talloc.
>
> Still I don't understand the sense of the error-message, any further
> suggestions are welcome.

1. Show more code and a way to reproduce it

2. Slim it down to a small testcase

3. Use VALGRIND_CHECK_VALUE_IS_DEFINED to track the specific byte that is 
causing the error and trace its origin.

4. Check the code with helgrind for race conditions.

Christoph,

> So I'm just trying to get the test case as well sanity-checked as we
> can, before sending it off to gcc-land.

Having looked at your test, it does look OK to me.

Can one or the other of you file a gcc bug report?

J

Julian Seward [mailto:jseward@...] wrote:

> Having looked at your test, it does look OK to me.
> 
> Can one or the other of you file a gcc bug report?

Christoph, you wrote the one that demonstrates a nice segfault 
without needing Valgrind to demonstrate the problem, so I guess
the honour is yours, unless you'd prefer me to do it. Please 
tell me the bug number so that I can chase SuSE to get a fix 
into their next service pack.

(I'm constrained from just installing updated versions of GCC
because the product I work on is a large and complex library, 
and customers get very nervous if I'm using a different compiler 
from them; so much so that they start reporting nonsense bugs). 

-- 
John Dallman
Parasolid Porting Engineer

Am Freitag, 25. April 2008 schrieb Dallman, John:

> Christoph, you wrote the one that demonstrates a nice segfault
> without needing Valgrind to demonstrate the problem, so I guess
> the honour is yours, unless you'd prefer me to do it. Please
> tell me the bug number so that I can chase SuSE to get a fix
> into their next service pack.


You can add yourself to the cc list:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043

Christoph Bartoschek [mailto:bartoschek@...] wrote:

> You can add yourself to the cc list:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043

Done. Thanks very much. 

-- 
John Dallman
Parasolid Porting Engineer

Andi Kleen [mailto:andi@...] wrote:
> Julian Seward <jseward@...> writes:
> > Also, it's worth checking the problem is reproducible on the
> > latest stable gcc (4.3.0).  Filing bug reports on older gccs is
> > imo pretty much pointless.
> When he has a support contract for his SLES he could file a bug
> report with Novell. That might result in a fix for that particular
> gcc version.

That's pretty much the plan, I've referred them to the GCC bugzilla
bug. 

thanks,

-- 
John Dallman
Parasolid Porting Engineer