valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/25/2014 5:45 AM, Skarakis, Konstantinos wrote:
> That's fantastic. Thank you very much for your time. It works great.

Good news that it works for someone else too!

I started updating the valgrind documentation to add description
of this new feature, and expect to submit a patch soon for
developer approval.

Regards - Eliot

Re: [Valgrind-users] Unique log filename

[Skarakis, K. <kon...@un...>]

That's fantastic. Thank you very much for your time. It works great. 

Here's how I am using it:

I have this line in my ~/.valgrindrc:

--log-file=/software/valgrind/rpts/%s{"/software/dstring"}-%p-report.txt

And these are the contents of /software/dstring:

echo $(ps -f $PPID | tail -n 1 | awk "{print \$10}")-$(date +%Y%m%d%H%M%S%N)

This results in this very nice log:

$ valgrind ls
cap.cap  cov  covfsn  md5r  rpts  rpts1  rpts_fsn_errors

$ ls /software/valgrind/rpts    
ls-20140925123940975544578-18453-report.txt


Kind Regards,
Costas


------------------------------

Message: 3
Date: Wed, 24 Sep 2014 09:51:38 -0400
From: Eliot Moss <mo...@cs...>
Subject: Re: [Valgrind-users] Unique log filename
To: "val...@li..."
	<val...@li...>
Message-ID: <542...@cs...>
Content-Type: text/plain; charset="windows-1252"

On 9/24/2014 7:39 AM, Eliot Moss wrote:
> On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:

Ok -- I decided to just give it a try in a copy of valgrind updated to svn head.  The issue is that I was temporarily sticking a null character into the format string, yet the format string was declared somewhere else as const.  That declaration was righteous, and my temporary insertion of a null I admit was a hack.  I was already copying the relevant part of the format string out into a temporary buffer, so the actual adjustments needed were small.  Once I made those changes, it compiles and passes check tests for me (on a linux amd64 system).  I attach the updated patch.  I'll see about submitting this, though there also needs to be an update to a section of the manual for a complete patch to make sense for the distro.

Regards -- Eliot Moss

Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container

[Tom H. <to...@co...>]

On 24/09/14 22:04, Vallevand, Mark K wrote:

> We don’t care about valgrind in the child process.  We need to get the
> child to detach from valgrind before it calls the lxc library.
>
> So, how can this be done?

It can't - valgrind is a fundamental part of the process and the only 
way to get rid of it is to exec into a different binary.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Problems with valgrind after a fork() and starting a container

[Vallevand, M. K <Mar...@UN...>]

In our program, we do a fork() and in the child process the lxc library is called to start a container.  The child process does not call exec().
Valgrind and lxc do not play nicely, at least with the versions in Ubuntu 12.04 LTS.
We don't care about valgrind in the child process.  We need to get the child to detach from valgrind before it calls the lxc library.
So, how can this be done?
Any suggestions will be welcome.  And, thanks!

Regards.
Mark K Vallevand
"If there are no dogs in Heaven, then when I die I want to go where they went."
-Will Rogers

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

Re: [Valgrind-users] can't compile valgrind 3.10.0 on SuSE Linux SLES 10SP3 64bit

[Florian K. <fl...@ei...>]

On 16.09.2014 02:27, Patrick J. LoPresti wrote:
> 
> I can confirm PTRACE_GETSIGINFO and PTRACE_SETSIGINFO are present in
> sys/ptrace.h for all architectures (including s390) as of glibc 2.5
> but not 2.4. Well, except for ia64, where they were added a little
> earlier (2.3).
> 
> Since Valgrind does not (yet) support ia64, (__GLIBC__ > 2) ||
> (__GLIBC__ == 2 && __GLIBC_MINOR__ > 4) -- suitably negated -- should
> do the trick...

Thanks. I've changed this in r14565.

   Florian

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/24/2014 7:39 AM, Eliot Moss wrote:
> On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:

Ok -- I decided to just give it a try in a copy of valgrind
updated to svn head.  The issue is that I was temporarily
sticking a null character into the format string, yet the
format string was declared somewhere else as const.  That
declaration was righteous, and my temporary insertion of
a null I admit was a hack.  I was already copying the
relevant part of the format string out into a temporary
buffer, so the actual adjustments needed were small.  Once
I made those changes, it compiles and passes check tests
for me (on a linux amd64 system).  I attach the updated
patch.  I'll see about submitting this, though there also
needs to be an update to a section of the manual for a
complete patch to make sense for the distro.

Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:

> I really appreciate this patch. It’s exactly what I was looking for. I must be doing something wrong
> though. When I apply the patch and try to “make” I get this error:
>
> m_options.c: In function âvgPlain_expand_file_nameâ:
>
> m_options.c:244: warning: assignment discards qualifiers from pointer target type
>
> m_options.c:252: error: assignment of read-only location â*(format + (long unsigned int)(long
> unsigned int)i)â
>
> m_options.c:253: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness
>
> m_options.c:254: warning: pointer targets in passing argument 1 of âvgPlain_strcpyâ differ in signedness
>
> m_options.c:254: warning: pointer targets in passing argument 2 of âvgPlain_strcpyâ differ in signedness
>
> m_options.c:256: error: assignment of read-only location â*(format + (long unsigned int)(long
> unsigned int)i)â
>
> m_options.c:279: warning: pointer targets in initialization differ in signedness
>
> m_options.c:279: warning: pointer targets in initialization differ in signedness
>
> m_options.c:280: warning: pointer targets in passing argument 1 of âvgPlain_execvâ differ in signedness
>
> m_options.c:280: warning: passing argument 2 of âvgPlain_execvâ from incompatible pointer type
>
> m_options.c:327: warning: implicit declaration of function âvgPlain_sigemptysetâ
>
> m_options.c:330: warning: implicit declaration of function âvgPlain_sigactionâ
>
> m_options.c:335: warning: implicit declaration of function âvgPlain_convert_sigaction_fromK_to_toKâ
>
> m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness
>
> m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness
>
> Line 252 is:
>
> format[i] = 0;
>
> Line 256 is:
>
>        format[i] = ‘}’;
>
> Maybe I didn’t apply the patch right…

The patch is against a somewhat older version of valgrind, and was also never
tested in other OS environments than my own.  My sense of the above is that
some declarations need adjustment around signed/unsigned and const or not,
or else rather than modifying 'format' in place, the code needs to copy the
relevant part out to a separate string.  Also, some of the routines I called
in the code (execva, sigaction, strlen) seem not to have their proper
declarations available.

I am sure this can all be solved, but I am not sure when I will have time to
work on porting it forward to present day valgrind.

Thoughts from the list?

Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Skarakis, K. <kon...@un...>]

Hi Eliot,



I really appreciate this patch. It's exactly what I was looking for. I must be doing something wrong though. When I apply the patch and try to "make" I get this error:



m_options.c: In function âvgPlain_expand_file_nameâ:

m_options.c:244: warning: assignment discards qualifiers from pointer target type

m_options.c:252: error: assignment of read-only location â*(format + (long unsigned int)(long unsigned int)i)â

m_options.c:253: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness

m_options.c:254: warning: pointer targets in passing argument 1 of âvgPlain_strcpyâ differ in signedness

m_options.c:254: warning: pointer targets in passing argument 2 of âvgPlain_strcpyâ differ in signedness

m_options.c:256: error: assignment of read-only location â*(format + (long unsigned int)(long unsigned int)i)â

m_options.c:279: warning: pointer targets in initialization differ in signedness

m_options.c:279: warning: pointer targets in initialization differ in signedness

m_options.c:280: warning: pointer targets in passing argument 1 of âvgPlain_execvâ differ in signedness

m_options.c:280: warning: passing argument 2 of âvgPlain_execvâ from incompatible pointer type

m_options.c:327: warning: implicit declaration of function âvgPlain_sigemptysetâ

m_options.c:330: warning: implicit declaration of function âvgPlain_sigactionâ

m_options.c:335: warning: implicit declaration of function âvgPlain_convert_sigaction_fromK_to_toKâ

m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness

m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness



Line 252 is:

format[i] = 0;

Line 256 is:

      format[i] = '}';





Maybe I didn't apply the patch right...



Kind Regards,

Costas



------------------------------



Date: Tue, 23 Sep 2014 14:11:01 -0400

From: Eliot Moss <mo...@cs...<mailto:mo...@cs...>>

Subject: Re: [Valgrind-users] Unique log filename

To: "val...@li...<mailto:val...@li...>"

      <val...@li...<mailto:val...@li...>>

Message-ID: <542...@cs...<mailto:542...@cs...>>

Content-Type: text/plain; charset="windows-1252"



Ok, here's the patch to add the %s{script} form

to log-file expansion.  The script is run via

/bin/bash -c script, and its output replaces the

while %s form.  The max length my code allows

for the result is 500 characters, which seemed

enough for anything realistic.  Note that the

pid of the invoking valgrind will be the script's

PPID, etc.



If the "powers that be" think this might be

generally useful, then let me know how you would

prefer to receive the patch, and any tidying you

feel would be in order ...



Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

Ok, here's the patch to add the %s{script} form
to log-file expansion.  The script is run via
/bin/bash -c script, and its output replaces the
while %s form.  The max length my code allows
for the result is 500 characters, which seemed
enough for anything realistic.  Note that the
pid of the invoking valgrind will be the script's
PPID, etc.

If the "powers that be" think this might be
generally useful, then let me know how you would
prefer to receive the patch, and any tidying you
feel would be in order ...

Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/23/2014 10:11 AM, Skarakis, Konstantinos wrote:
> Hello,
>
> I want to run a big project over a long time under Valgrind’s Memcheck. I am using --log-file in
> conjunction with %p to generate log files per process ID. This means that over time I will start
> losing log files due to PID reuse. Is there a way to make my logs unique so that they will not be
> overwritten? Maybe some way to get a timestamp in the filename? I know that the only other available
> specifier is %q, but I haven’t found a way to make this work.
>
> I am running on Suse Linux 64bit.
>
> Thanks,
>
> Costas

Dear Costas -- I am not aware of anything to do that, but a while back
I wrote a patch that allows an additional format specifier, %s{....}
which runs a script and argument that are specified in the {....},
and the result of that script is used as the file name for the log
file.  It would be easy enough, given that functionality, to write
a script that returns a time stamp.  I will see if I can narrow this
down to a small patch that I can submit, and when I do, I can email
you the patch at the same time.  I did this a while ago, but if this
part of the code has not been changed a lot, then the patch should
not be too bad to extract.

I've been meaning to submit it for some time, actually, and this is
a good prompt to make me do it!

Regards -- Eliot Moss

[Valgrind-users] Unique log filename

[Skarakis, K. <kon...@un...>]

Hello,

I want to run a big project over a long time under Valgrind's Memcheck. I am using --log-file in conjunction with %p to generate log files per process ID. This means that over time I will start losing log files due to PID reuse. Is there a way to make my logs unique so that they will not be overwritten? Maybe some way to get a timestamp in the filename? I know that the only other available specifier is %q, but I haven't found a way to make this work.

I am running on Suse Linux 64bit.

Thanks,
Costas

[Valgrind-users] Valgrind and glibc's CPU detection

[Konstantin T. <an...@ya...>]

Hi all,

I'd like to prevent glibc from using any SIMD-optimized functions when running application under Valgrind on Linux. Is it possible to do now?
AFAIU, glibc uses runtime CPU detection, and Valgrind runs code on emulated CPU.

-- 
Regards,
Konstantin

[Valgrind-users] Wrapping function for strcpy

[Myoungkyu S. <mks...@gm...>]

Hello,

I have a question, which maybe was discussed.  I would like to implement a
wrapper function for standard API such as "strcpy".  However, I failed to
do.  When I tested a user-defined function like "hello(char *, char *)"
below, I successfully wrapped it, accessing to arguments and a return
value.  Please see the code being as followings.  I have tested in Ubuntu
14.04.1 (installed at VirtualBox), gcc 4.8.2, and valgrind-3.10.0.

I'd appreciate it if you'd share your comments or advice.

Thanks in advance,
Myoungkyu

// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// run/output
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mksong@mksong:testwrap$ ../inst/bin/valgrind --tool=testinst ./w_main
==3747== Testinstgrind, the minimal Valgrind tool
==3747==
==3747== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==3747== Command: ./w_main
==3747==
wrapper-pre-hello: 4 4
hello
wrapper-post-hello
==3747==

// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// w_main.c
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include "valgrind.h"

extern void hello ( char *dest, const char *src );

void I_WRAP_SONAME_FNNAME_ZU(NONE,hello) ( char *dest, const char *src )
{
   OrigFn fn;
   VALGRIND_GET_ORIG_FN(fn);
   printf("wrapper-pre-hello: %d %d\n", sizeof(dest), sizeof(src));
   CALL_FN_v_WW(fn, dest, src);
   printf("wrapper-post-hello\n");
}

char* I_WRAP_SONAME_FNNAME_ZU(NONE,strcpy) ( char *dest, const char *src )
{
   OrigFn fn;
   char *result;
   VALGRIND_GET_ORIG_FN(fn);
   printf("wrapper-pre-strcpy\n");
   CALL_FN_W_WW(result, fn, dest, src);
   printf("wrapper-post-strcpy\n");
   return result;
}

int main(int argc, char** argv) {
char *str;
str = (char *) malloc(15);
hello(str, "Hello world");
strcpy(str, "Hello strcpy!");
return 1;
}

// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// hello.c
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void hello(char dest[], const char *src) {
    printf( "hello\n");
}

// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// ti_main.c <not yet developed>
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include "pub_tool_basics.h"
#include "pub_tool_tooliface.h"

static void ti_post_clo_init(void)
{
}

static
IRSB* ti_instrument ( VgCallbackClosure* closure,
                      IRSB* bb,
                      VexGuestLayout* layout,
                      VexGuestExtents* vge,
                      VexArchInfo* archinfo_host,
                      IRType gWordTy, IRType hWordTy )
{
    return bb;
}

static void ti_fini(Int exitcode)
{
}

static void ti_pre_clo_init(void)
{
   VG_(details_name)            ("Testinstgrind");
   VG_(details_version)         (NULL);
   VG_(details_description)     ("the minimal Valgrind tool");
   VG_(details_copyright_author)("");
   VG_(details_bug_reports_to)  (VG_BUGS_TO);

   VG_(details_avg_translation_sizeB) ( 275 );

   VG_(basic_tool_funcs)        (ti_post_clo_init,
                                 ti_instrument,
                                 ti_fini);

   /* No needs, no core events to track */
}

VG_DETERMINE_INTERFACE_VERSION(ti_pre_clo_init)

/*--------------------------------------------------------------------*/
/*--- end                                                          ---*/
/*--------------------------------------------------------------------*/

Re: [Valgrind-users] [Valgrind-developers] Valgrind regression suite: Possible to cross compile & run native?

[Philippe W. <phi...@sk...>]

On Mon, 2014-09-22 at 16:17 +0000, Anmol Paralkar wrote:
> Hello,
> 
>  
> 
> Is it possible to cross compile the valgrind regression suite and then
> execute it natively?
I did not retry recently but IIRC, the below worked some weeks
ago on arm64 emulator running fedora:
   make regtest on the host side
     (this will fail when starting to execute the tests, just interrupt it)
   copy all the valgrind directory (not only the 'install dir' to the target
   on the target, do:
       perl tests/vg_regtest --all

Philippe

Note that this type of question is better suited for
valgrind-developers, so it is good enough to ask it on that list.

[Valgrind-users] Valgrind regression suite: Possible to cross compile & run native?

[Anmol P. <An...@fr...>]

Hello,

Is it possible to cross compile the valgrind regression suite and then execute it natively?

Thanks,
Anmol.

[Valgrind-users] Valgrind ARMv7 (Cortex A7) - Linux regression results?

[Anmol P. <An...@fr...>]

Hello,

  If you have results for Valgrind regression testing on a ARMv7 Cortex A7 on Linux
 that can be used as reference, please could you share them.

Thanks,
Anmol.

Re: [Valgrind-users] lockup using valgrind on powerpc with eglibc-2.16

[Chris P. <jud...@gm...>]

On Thu, Sep 18, 2014 at 9:35 PM, Chris Packham <jud...@gm...> wrote:
> Hi,
>
> I'm trying to use valgrind on an embedded powerpc system. When I start
> a process under valgrind the it seems to lock up. I can connect to the
> process using gdb/vgdb and the the following backtrace
>
>   #0  0x0ffbaba8 in _vgr20190ZU_ldZdsoZd1_bcmp (s1V=0x401d000,
> s2V=0x401a2e7, n=11) at ../shared/vg_replace_strmem.c:974
>   #1  0x0ffbabac in _vgr20190ZU_ldZdsoZd1_bcmp (s1V=<optimized out>,
> s2V=<optimized out>, n=<error reading variable: value has been
> optimized out>) at ../shared/vg_replace_strmem.c:974
>
> Originally I thought it was a problem with 3.10.0 but I've tried a few
> versions and they all seem to have the same type of issue so I think
> it's something about our system causing the problem.
>
> We have successfully run valgrind 3.7.0 on an earlier version of our
> system using uclibc (after a few patches). I did a quick test with
> 3.7.0 after convincing configure to allow eglibc-2.16 and got the same
> behaviour but given the fact that 3.7.0 doesn't claim to support
> glib-2.16 I'm not sure how valid that result is.
>
> Has anyone got any clues as to what I need to do to get valgrind
> running on this system?
>
> Thanks,
> Chris

Update. I was able to try a mips based target and valgrind works fine.
So this appears to be specific to powerpc. If it helps here is some
output from a powerpc target vs a mips target

POWERPC:

$ valgrind --verbose more /proc/self/cmdline
==6250== Memcheck, a memory error detector
==6250== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6250== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==6250== Command: more /proc/self/cmdline
==6250==
--6250-- Valgrind options:
--6250--    --verbose
--6250-- Contents of /proc/version:
--6250--   Linux version 3.6.11 (@chrisp-dl) (gcc version 4.6.3
(Gentoo 4.6.3-r1 p1.9, pie-0.5.2) ) #1 SMP Thu Sep 18 14:22:06 NZST 2
014
--6250-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX
--6250-- Page sizes: currently 4096, max supported 65536
--6250-- Valgrind library directory: /usr/lib/valgrind
--6250-- Reading syms from /lib/ld-2.16.so
--6250-- Reading syms from /bin/more
--6250--    object doesn't have a symbol table
--6250-- Reading syms from /usr/lib/valgrind/memcheck-ppc32-linux
--6250--    object doesn't have a symbol table
--6250--    object doesn't have a dynamic symbol table
--6250-- Scheduler: using generic scheduler lock implementation.
--6250-- Reading suppressions file: /usr/lib/valgrind/default.supp
==6250== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-6250-by-root-on-AT_SBx81CFC960
==6250== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-6250-by-root-on-AT_SBx81CFC960
==6250== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-6250-by-root-on-AT_SBx81CFC960
==6250==
==6250== TO CONTROL THIS PROCESS USING vgdb (which you probably
==6250== don't want to do, unless you know exactly what you're doing,
==6250== or are doing some strange experiment):
==6250==   /usr/lib/valgrind/../../bin/vgdb --pid=6250 ...command...
==6250==
==6250== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==6250==   /path/to/gdb more
==6250== and then give GDB the following command
==6250==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=6250
==6250== --pid is optional if only one valgrind process is running
==6250==
--6250-- REDIR: 0x4016c58 (ld.so.1:strlen) redirected to 0x3806c5a0 (???)
--6250-- REDIR: 0x4016a90 (ld.so.1:strcmp) redirected to 0x3806c5c8 (???)
--6250-- REDIR: 0x40169b4 (ld.so.1:index) redirected to 0x3806c63c (???)
--6250-- Reading syms from /usr/lib/valgrind/vgpreload_core-ppc32-linux.so
--6250--    object doesn't have a symbol table
--6250-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so
--6250--    object doesn't have a symbol table
--6250-- REDIR: 0x40176f8 (ld.so.1:memcpy) redirected to 0xffb9fa4 (memcpy)
<hang>

MIPS:
$  valgrind --verbose more /proc/self/cmdline
==13966== Memcheck, a memory error detector
==13966== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==13966== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==13966== Command: more /proc/self/cmdline
==13966==
--13966-- Valgrind options:
--13966--    --verbose
--13966-- Contents of /proc/version:
--13966--   Linux version 3.6.11-at1 (@chrisp-dl) (gcc version 4.6.3
(Gentoo 4.6.3-r1 p1.9, pie-0.5.2) ) #1 Thu Sep 18 17:23:47 NZST
2014
--13966-- Arch and hwcaps: MIPS32, BigEndian, Broadcom-baseline
--13966-- Page sizes: currently 4096, max supported 4096
--13966-- Valgrind library directory: /usr/lib/valgrind
--13966-- Reading syms from /bin/more
--13966--    object doesn't have a symbol table
--13966-- Reading syms from /lib/ld-2.16.so
--13966-- Reading syms from /usr/lib/valgrind/memcheck-mips32-linux
--13966--    object doesn't have a symbol table
--13966--    object doesn't have a dynamic symbol table
--13966-- Scheduler: using generic scheduler lock implementation.
--13966-- Reading suppressions file: /usr/lib/valgrind/default.supp
==13966== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-13966-by-root-on-x510_52GTX
==13966== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-13966-by-root-on-x510_52GTX
==13966== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-13966-by-root-on-x510_52GTX
==13966==
==13966== TO CONTROL THIS PROCESS USING vgdb (which you probably
==13966== don't want to do, unless you know exactly what you're doing,
==13966== or are doing some strange experiment):
==13966==   /usr/lib/valgrind/../../bin/vgdb --pid=13966 ...command...
==13966==
==13966== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==13966==   /path/to/gdb more
==13966== and then give GDB the following command
==13966==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=13966
==13966== --pid is optional if only one valgrind process is running
==13966==
--13966-- Reading syms from /usr/lib/valgrind/vgpreload_core-mips32-linux.so
--13966--    object doesn't have a symbol table
--13966-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-mips32-linux.so
--13966--    object doesn't have a symbol table
--13966-- REDIR: 0x4019980 (ld.so.1:bcmp) redirected to 0x484c8f8 (bcmp)
--13966-- REDIR: 0x4019fc0 (ld.so.1:memcpy) redirected to 0x484bef0 (memcpy)
--13966-- REDIR: 0x4019ea0 (ld.so.1:mempcpy) redirected to 0x484da94 (mempcpy)
--13966-- Reading syms from /usr/lib/libncurses.so.5.9
--13966--    object doesn't have a symbol table
--13966-- Reading syms from /lib/libpthread-2.16.so
--13966-- Reading syms from /lib/libc-2.16.so
==13966== Invalid write of size 4
==13966==    at 0x4001348: _dl_start_user (in /lib/ld-2.16.so)
==13966==    by 0x40012DC: __start (in /lib/ld-2.16.so)
==13966==  Address 0x7eab38cc is on thread 1's stack
==13966==  4 bytes below stack pointer
==13966==
--13966-- REDIR: 0x49483d0 (libc.so.6:memset) redirected to 0x484d0b8 (memset)
--13966-- REDIR: 0x4948b30 (libc.so.6:memcpy) redirected to 0x484b650 (memcpy)
--13966-- REDIR: 0x49470e0 (libc.so.6:rindex) redirected to 0x48493b0 (rindex)
--13966-- REDIR: 0x4946780 (libc.so.6:strcmp) redirected to 0x484ae1c (strcmp)
--13966-- REDIR: 0x4946d30 (libc.so.6:strlen) redirected to 0x4849ad8 (strlen)
--13966-- REDIR: 0x4946f60 (libc.so.6:strncmp) redirected to 0x484a328 (strncmp)
--13966-- REDIR: 0x4946690 (libc.so.6:index) redirected to 0x4849608 (index)
--13966-- REDIR: 0x4942134 (libc.so.6:free) redirected to 0x4847330 (free)
--13966-- REDIR: 0x4941a30 (libc.so.6:malloc) redirected to 0x4848d60 (malloc)
--13966-- REDIR: 0x4948460 (libc.so.6:mempcpy) redirected to 0x484d95c (mempcpy)
--13966-- REDIR: 0x494296c (libc.so.6:calloc) redirected to 0x4845fc0 (calloc)
--13966-- REDIR: 0x494a620 (libc.so.6:strchrnul) redirected to
0x484d7b0 (strchrnul)
--13966-- REDIR: 0x4946de0 (libc.so.6:strnlen) redirected to 0x4849a70 (strnlen)
--13966-- REDIR: 0x4947978 (libc.so.6:strstr) redirected to 0x484df98 (strstr)
--13966-- REDIR: 0x4947010 (libc.so.6:strncpy) redirected to 0x4849e28 (strncpy)
more/proc/self/cmdline
==13966==
==13966== HEAP SUMMARY:
==13966==     in use at exit: 8,514 bytes in 8 blocks
==13966==   total heap usage: 13 allocs, 5 frees, 9,288 bytes allocated
==13966==
==13966== Searching for pointers to 8 not-freed blocks
==13966== Checked 80,244 bytes
==13966==
==13966== LEAK SUMMARY:
==13966==    definitely lost: 0 bytes in 0 blocks
==13966==    indirectly lost: 0 bytes in 0 blocks
==13966==      possibly lost: 0 bytes in 0 blocks
==13966==    still reachable: 8,514 bytes in 8 blocks
==13966==         suppressed: 0 bytes in 0 blocks
==13966== Rerun with --leak-check=full to see details of leaked memory
==13966==
==13966== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==13966==
==13966== 1 errors in context 1 of 1:
==13966== Invalid write of size 4
==13966==    at 0x4001348: _dl_start_user (in /lib/ld-2.16.so)
==13966==    by 0x40012DC: __start (in /lib/ld-2.16.so)
==13966==  Address 0x7eab38cc is on thread 1's stack
==13966==  4 bytes below stack pointer
==13966==
==13966== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Re: [Valgrind-users] where to find not-quite-current tarballs

[Mark W. <mj...@re...>]

On Thu, 2014-09-18 at 15:10 +0200, Mark Abraham wrote:
> Hi John,
> 
> Thanks, I found a previously-used 3.9.0 tarball on one of my own machines.
> Still, a list of links on the main valgrind homepage would be a nice
> convenience.

Yeah, looks like we have to update the archive page. Some of the old
releases not on the archive page should be:

http://valgrind.org/downloads/valgrind-3.9.0.tar.bz2
valgrind 3.9.0 (tar.bz2) [10MB] - 31 October 2013.
For {x86,amd64,arm,ppc32,ppc64,s390x,mips32,mips64}-linux, arm-android
(2.3 and later), x86-android (4.0 and later) and {x86,amd64}-darwin (Mac
OS X 10.7, with limited support for 10.8).
md5: 0947de8112f946b9ce64764af7be6df2

http://valgrind.org/downloads/valgrind-3.8.1.tar.bz2
valgrind 3.8.1 (tar.bz2) [7962Kb] - 19 September 2012.
For {x86,amd64,arm,ppc32,ppc64,s390x,mips32}-linux, arm-android (2.3 and
later), x86-android (4.0 and later) and {x86,amd64}-darwin (Mac OS X
10.6 and 10.7, with limited support for 10.8).
md5: 288758010b271119a0ffc0183f1d6e38

http://valgrind.org/downloads/valgrind-3.8.0.tar.bz2
valgrind 3.8.0 (tar.bz2) [7961Kb] - 10 August 2012.
For {x86,amd64,arm,ppc32,ppc64,s390x,mips32}-linux, arm-android (2.3 and
later), x86-android (4.0 and later) and {x86,amd64}-darwin (Mac OS X
10.6 and 10.7, with limited support for 10.8).
md5: ec04dfd1256307432b2a7b520398c526

http://valgrind.org/downloads/valgrind-3.7.0.tar.bz2
valgrind 3.7.0 (tar.bz2) [6624Kb] - 5 November 2011.
For {x86,amd64,arm,ppc32,ppc64,s390x}-linux, arm-android (2.3.x) and
{x86,amd64}-darwin (Mac OS X 10.6 and 10.7).
md5: a855fda56edf05614f099dca316d1775

Re: [Valgrind-users] where to find not-quite-current tarballs

[Tom H. <to...@co...>]

On 18/09/14 13:12, Mark Abraham wrote:

> After finding an issue with valgrind 3.10 that was not observed in
> earlier versions, I went looking for 3.9 tarball to see whether I could
> reproduce the issue there. However, neither
> http://valgrind.org/downloads/current.html nor
> http://valgrind.org/downloads/old.html have links to tarballs between
> 3.4.2 and 3.10. Where should I look for these, please?

It's still there:

   http://valgrind.org/downloads/valgrind-3.9.0.tar.bz2

It just isn't linked from any of the pages.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] where to find not-quite-current tarballs

[Mark A. <mar...@gm...>]

Hi John,

Thanks, I found a previously-used 3.9.0 tarball on one of my own machines.
Still, a list of links on the main valgrind homepage would be a nice
convenience.

Mark

On Thu, Sep 18, 2014 at 2:42 PM, John Reiser <jr...@bi...> wrote:

> > neither http://valgrind.org/downloads/current.html nor
> http://valgrind.org/downloads/old.html have links to tarballs between
> > 3.4.2 and 3.10. Where should I look for these, please?
>
> Search the web for the filename.
>
> I have these lying around, and can send you a copy:
>  5482423 Feb 22  2010 valgrind-3.5.0.tar.bz2
>  5477407 Aug 17  2009 valgrind-3.5.0-TEST2.tar.bz2
>  5962204 Oct 23  2010 valgrind-3.6.0.tar.bz2
>  7961355 Aug 14  2012 valgrind-3.8.0.tar.bz2
>  7962963 Oct  4  2012 valgrind-3.8.1.tar.bz2
> 10003156 Nov  1  2013 valgrind-3.9.0.tar.bz2
>
> --
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] where to find not-quite-current tarballs

[John R. <jr...@Bi...>]

> neither http://valgrind.org/downloads/current.html nor http://valgrind.org/downloads/old.html have links to tarballs between
> 3.4.2 and 3.10. Where should I look for these, please?

Search the web for the filename.

I have these lying around, and can send you a copy:
 5482423 Feb 22  2010 valgrind-3.5.0.tar.bz2
 5477407 Aug 17  2009 valgrind-3.5.0-TEST2.tar.bz2
 5962204 Oct 23  2010 valgrind-3.6.0.tar.bz2
 7961355 Aug 14  2012 valgrind-3.8.0.tar.bz2
 7962963 Oct  4  2012 valgrind-3.8.1.tar.bz2
10003156 Nov  1  2013 valgrind-3.9.0.tar.bz2

-- 

[Valgrind-users] where to find not-quite-current tarballs

[Mark A. <mar...@gm...>]

Hi,

After finding an issue with valgrind 3.10 that was not observed in earlier
versions, I went looking for 3.9 tarball to see whether I could reproduce
the issue there. However, neither http://valgrind.org/downloads/current.html
nor http://valgrind.org/downloads/old.html have links to tarballs between
3.4.2 and 3.10. Where should I look for these, please?

Thanks!

Mark

[Valgrind-users] lockup using valgrind on powerpc with eglibc-2.16

[Chris P. <jud...@gm...>]

Hi,

I'm trying to use valgrind on an embedded powerpc system. When I start
a process under valgrind the it seems to lock up. I can connect to the
process using gdb/vgdb and the the following backtrace

  #0  0x0ffbaba8 in _vgr20190ZU_ldZdsoZd1_bcmp (s1V=0x401d000,
s2V=0x401a2e7, n=11) at ../shared/vg_replace_strmem.c:974
  #1  0x0ffbabac in _vgr20190ZU_ldZdsoZd1_bcmp (s1V=<optimized out>,
s2V=<optimized out>, n=<error reading variable: value has been
optimized out>) at ../shared/vg_replace_strmem.c:974

Originally I thought it was a problem with 3.10.0 but I've tried a few
versions and they all seem to have the same type of issue so I think
it's something about our system causing the problem.

We have successfully run valgrind 3.7.0 on an earlier version of our
system using uclibc (after a few patches). I did a quick test with
3.7.0 after convincing configure to allow eglibc-2.16 and got the same
behaviour but given the fact that 3.7.0 doesn't claim to support
glib-2.16 I'm not sure how valid that result is.

Has anyone got any clues as to what I need to do to get valgrind
running on this system?

Thanks,
Chris

[Valgrind-users] valgrind-3.10 does not link on

[Matthias A. <gu...@un...>]

Hello,

This is on a Linux host running:

valgrind-3.10.0> uname -a
Linux SRAP03DXOH 2.6.5-7.191-bigsmp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 athlon i386 GNU/Linux

valgrind-3.10.0> CFLAGS="-DPTRACE_GETSIGINFO=0x4202" export CFLAGS
valgrind-3.10.0> ./configure
valgrind-3.10.0> gmake
...

mv -f .deps/memcheck_x86_linux-mc_errors.Tpo .deps/memcheck_x86_linux-mc_errors.Po
../coregrind/link_tool_exe_linux 0x38000000 gcc  -Wno-long-long -DPTRACE_GETSIGINFO=0x4202   -o memcheck-x86-linux -m32 -mpreferred-stack-boundary=2 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -O2 -static -nodefaultlibs -nostartfiles -u _start  -m32 memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o memcheck_x86_linux-mc_machine.o memcheck_x86_linux-mc_errors.o ../coregrind/libcoregrind-x86-linux.a ../VEX/libvex-x86-linux.a -lgcc 
../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x14bba): In function `vgSysWrap_linux_sys_ioctl_after':
m_syswrap/syswrap-linux.c:8476: undefined reference to `__builtin_popcountll'
../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x1ddcb): In function `vgSysWrap_linux_sys_ioctl_before':
m_syswrap/syswrap-linux.c:5748: undefined reference to `__builtin_popcountll'
collect2: ld returned 1 exit status
gmake[3]: *** [memcheck-x86-linux] Error 1
gmake[3]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0'
gmake: *** [all] Error 2

Vy 73

         matthias
-- 
Matthias Apitz
Development Lead SunRise - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany tel +49-89-61308 351 - fax +49-89-61308 399 - mobile +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5




----- End forwarded message -----

-- 
Matthias Apitz               |  /"\   ASCII Ribbon Campaign:
E-mail: gu...@un...     |  \ /   - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X    - No proprietary attachments
phone: +49-170-4527211       |  / \   - Respect for open standards
                             | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

[Valgrind-users] multi thread app on mips embeded system

[Echo z. <zha...@gm...>]

Hi,

  I have installed valgrind in my mips embeded board, and run a multi
thread app with it,
but about 80% I would encounter the valgrind down as bellow:


done_this_time 0, dispatchctrp 93804, host_evc_counter 93803
done_this_time 0, dispatchctrp 93804, host_evc_counter 93803
done_this_time -1, dispatchctrp 93804, host_evc_counter 93804 <==== I try
to add debug print for this reason

valgrind: m_scheduler/scheduler.c:959 (run_thread_for_a_while): Assertion
'done_this_time >= 0' failed.
==1519==    at 0x3803E0E0: ??? (in /lib/memcheck-mips32-linux)
==1519==    by 0x3803E018: ??? (in /lib/memcheck-mips32-linux)

  I wonder to know is this valgrind's issue or my app's issue, and if it is
app's , how to fix that ?

Linux version 3.4.11-rt19  (gcc version 4.6.2 (Buildroot 2011.11)
cpu: Broadcom BMIPS4350 V8.0


Regards,
he