valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Julian S. <js...@ac...>]

> I took a look at  https://bugs.kde.org/show_bug.cgi?id=306587 as you 
> suggested and it seems to be the same issue. The patch there is the same I 
> tried in my installation. But just want to make sure it is correct.

Per the discussion in 306587, if it is true that (1) V assumes that
dcache.linesize == icache.linesize, and (2) that the CPU in question
has different values for these, then we need to change V so that it
doesn't make that assumption.  Patches welcome ..

J

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Vishal <vis...@gm...>]

> Hi Vishal,
> 
>  How about the other experiment where you build Valgrind with the default 
optimization
>  level turned off? i.e. start over (do a: make clean) and then do a: make 
CFLAGS="-O0 -g" 
> 
>  Also, I tried the following out:
> 
> ----
> anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> git diff 
coregrind/m_machine.c
> diff --git a/coregrind/m_machine.c b/coregrind/m_machine.c
> index 6a77057..122674a 100644
> --- a/coregrind/m_machine.c
> +++ b/coregrind/m_machine.c
>  <at>  <at>  -1465,6 +1465,8  <at>  <at>  void 
VG_(machine_ppc64_set_clszB)( Int szB )
>  {
>     vg_assert(hwcaps_done);
> 
> +   VG_(printf)("\nmachine_ppc64_set_clszB() (post-
entry)/(vai.ppc_cache_line_szB: %d, szB:
> %d)\n", vai.ppc_cache_line_szB, szB);
> +
>     /* Either the value must not have been set yet (zero) or we can
>        tolerate it being set to the same value multiple times, as the
>        stack scanning logic in m_main is a bit stupid. */
>  <at>  <at>  -1473,6 +1475,7  <at>  <at>  void 
VG_(machine_ppc64_set_clszB)( Int szB )
> 
>     vg_assert(szB == 32 || szB == 64 || szB == 128);
>     vai.ppc_cache_line_szB = szB;
> +   VG_(printf)("\nmachine_ppc64_set_clszB() (pre-
exit)/(vai.ppc_cache_line_szB: %d, szB: %d)\n",
> vai.ppc_cache_line_szB, szB);
>  }
> anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> ./bin/valgrind --leak-
check=full ~/hello
> 
> machine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: 0, szB: 
128)
> 
> machine_ppc64_set_clszB() (pre-exit)/(vai.ppc_cache_line_szB: 128, szB: 
128)
> 
> machine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: 128, szB: 
128)
> 
> machine_ppc64_set_clszB() (pre-exit)/(vai.ppc_cache_line_szB: 128, szB: 
128)
> 
> /* Usual Valgrind output... */
> anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1>
> ----
> 
>  If you could do the similar experiment for your Valgrind, we'll learn 
something about what is going on.
> 
> Regards,
> Anmol.

Hi Anmol,

Here's the dump you asked for.

machine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: 0, szB: 128)

machine_ppc64_set_clszB() (pre-exit)/(vai.ppc_cache_line_szB: 128, szB: 128)

machine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: 128, szB: 
32)

valgrind: m_machine.c:1382 (vgPlain_machine_ppc32_set_clszB): Assertion 
'vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB' failed.
==12374==    at 0x38035274: ??? (in 
/workspace/sw/vishald/etc/lib/valgrind/memcheck-ppc32-linux)

sched status:
  running_tid=0

I took a look at  https://bugs.kde.org/show_bug.cgi?id=306587 as you 
suggested and it seems to be the same issue. The patch there is the same I 
tried in my installation. But just want to make sure it is correct.

Warm Regards,
Vishal

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Paralkar Anmol-B. <B0...@fr...>]

> -----Original Message-----
> From: Vishal [mailto:vis...@gm...]
> Sent: Wednesday, July 31, 2013 12:02 AM
> To: val...@li...
> Subject: Re: [Valgrind-users] Valgrind throws assertion on powerpc while
> trying to run 'ls'
> 
> >
> > Hi Vishal,
> >
> >  I do not have a PPC476 FP system, so I cannot attempt to reproduce the
> issue.
> >  But, we need to understand what is going on. I tried this on the IBM
> POWER 7
> >  system I have here at work (see log below). Please could you try the
> corresponding
> >  debug session on your PPC476 FP system?
> >
> >  Note the comment in the code: "Either the value must not have been set
> yet (zero) or we can
> >  tolerate it being set to the same value multiple times, ..." In the log
> below,
> >  we see that vgPlain_machine_ppc64_set_clszB() is invoked twice before
> >  Valgrind/memcheck exits, each time with szB=128. What happens in your
> case?
> >
> >  When vgPlain_machine_ppc32_set_clszB() is invoked for the first time, at
> entry time:
> >  Is vai.ppc_cache_line_szB == 0? What is the value of szB?
> >
> >  Is vgPlain_machine_ppc32_set_clszB() invoked more than once? What value
> does
> >  vai.ppc_cache_line_szB hold each time? What value does szB hold each
> time?
> >
> >  Essentially, why does: vai.ppc_cache_line_szB == 0 ||
> vai.ppc_cache_line_szB == szB fail?
> >  Either at the first invocation vai.ppc_cache_line_szB != 0 or at a
> subsequent invocation,
> >  szB changes what already exists in vai.ppc_cache_line_szB - why?
> >
> >  One other try: Likely, you are compiling Valgrind optimized by default.
> What if you compile
> >  it with optimization turned off: make CFLAGS="-O0 -g"? Does the assert
> still happen?
> >
> > Regards,
> > Anmol.
> >
> > anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> gdb bin/valgrind
> > GNU gdb (GDB) Fedora (7.3.50.20110722-9.fc16)
> > Copyright (C) 2011 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "ppc64-redhat-linux-gnu".
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>...
> > Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
> 3.8.1/bin/valgrind...done.
> > (gdb) add-inferior -exec lib/valgrind/memcheck-ppc64-linux
> > Added inferior 2
> > Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
> 3.8.1/lib/valgrind/memcheck-ppc64-linux...done.
> > (gdb) inferior 2
> > [Switching to inferior 2 [process 0]
> (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-
> ppc64-linux)]
> > (gdb) break vgPlain_machine_ppc64_set_clszB
> > Breakpoint 1 at 0x38078354: file m_machine.c, line 1465.
> > (gdb) inferior 1
> > [Switching to inferior 1 [process 0]
> (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind)]
> > (gdb) run ~/hello
> > Starting program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
> 3.8.1/bin/valgrind ~/hello
> > process 7757 is executing new program:
> /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-
> ppc64-linux
> > Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-
> 24.fc16.7.ppc64
> >
> > Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at
> m_machine.c:1465
> > 1465    {
> > (gdb) bt
> > #0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
> > #1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized
> out>,
> > clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8,
> orig_envp=0x402010260, init_sp=0xfffffffeec0)
> >     at m_initimg/initimg-linux.c:725
> > #2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
> > #3  0x000000003807b748 in valgrind_main (argc=<optimized out>,
> argv=0xfffffffeec8,
> > envp=0xfffffffeee0) at m_main.c:1852
> > #4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at
> m_main.c:2994
> > #5  0x0000000038078608 in ._start ()
> > (gdb) c
> > Continuing.
> >
> > Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at
> m_machine.c:1465
> > 1465    {
> > (gdb) bt
> > #0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
> > #1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized
> out>,
> > clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8,
> orig_envp=0x402010260, init_sp=0xfffffffeec0)
> >     at m_initimg/initimg-linux.c:725
> > #2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
> > #3  0x000000003807b748 in valgrind_main (argc=<optimized out>,
> argv=0xfffffffeec8,
> > envp=0xfffffffeee0) at m_main.c:1852
> > #4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at
> m_main.c:2994
> > #5  0x0000000038078608 in ._start ()
> > (gdb) c
> > Continuing.
> > ==7822== Memcheck, a memory error detector
> > ==7822== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> > ==7822== Using Valgrind-3.8.1-FSL-SDK-1.4-spe-Fri-May-24-080638-PDT-2013
> and LibVEX; rerun with
> > -h for copyright info
> > ==7822== Command: /home/anmol/hello
> > ==7822==
> > ==7822== Invalid write of size 4
> > ==7822==    at 0x10000540: main (hello.c:8)
> > ==7822==  Address 0x4040044 is 0 bytes after a block of size 4 alloc'd
> > ==7822==    at 0x40281FC: malloc (vg_replace_malloc.c:270)
> > ==7822==    by 0x10000523: main (hello.c:6)
> > ==7822==
> > ==7822==
> > ==7822== HEAP SUMMARY:
> > ==7822==     in use at exit: 4 bytes in 1 blocks
> > ==7822==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
> > ==7822==
> > ==7822== LEAK SUMMARY:
> > ==7822==    definitely lost: 4 bytes in 1 blocks
> > ==7822==    indirectly lost: 0 bytes in 0 blocks
> > ==7822==      possibly lost: 0 bytes in 0 blocks
> > ==7822==    still reachable: 0 bytes in 0 blocks
> > ==7822==         suppressed: 0 bytes in 0 blocks
> > ==7822== Rerun with --leak-check=full to see details of leaked memory
> > ==7822==
> > ==7822== For counts of detected and suppressed errors, rerun with: -v
> > ==7822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> > [Inferior 1 (process 7822) exited normally]
> > (gdb)
> >
> 
> Hi Anmol,
> 
> I could not try GDB session as you suggested below. Unfortunately add-
> inferior command is not supported on our installation. I tried to put
> printf
> in the code but that gave vague errors. Next I tried to put some asserts at
> the same place like:
> 
> 1. vg_assert(vai.ppc_cache_line_szB == 0)
> 2. vg_assert(vai.ppc_cache_line_szB == szB)
> 3. vg_assert(szB != 0)
> 4. vg_assert(szB != 32)
> 5. vg_assert(szB != 64)
> 6. vg_assert(szB != 128)
> 
> The test failed again at line (2) above. Will this information help? Do you
> want me to try something else?
> 
> Warm Regards,
> Vishal

Hi Vishal,

 Please see: https://bugs.kde.org/show_bug.cgi?id=306587 for an explanation on
 what seems to be the problem.

Regards,
Anmol.

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Paralkar Anmol-B. <B0...@fr...>]

> -----Original Message-----
> From: Vishal [mailto:vis...@gm...]
> Sent: Wednesday, July 31, 2013 12:02 AM
> To: val...@li...
> Subject: Re: [Valgrind-users] Valgrind throws assertion on powerpc while
> trying to run 'ls'
> 
> >
> > Hi Vishal,
> >
> >  I do not have a PPC476 FP system, so I cannot attempt to reproduce the
> issue.
> >  But, we need to understand what is going on. I tried this on the IBM
> POWER 7
> >  system I have here at work (see log below). Please could you try the
> corresponding
> >  debug session on your PPC476 FP system?
> >
> >  Note the comment in the code: "Either the value must not have been set
> yet (zero) or we can
> >  tolerate it being set to the same value multiple times, ..." In the log
> below,
> >  we see that vgPlain_machine_ppc64_set_clszB() is invoked twice before
> >  Valgrind/memcheck exits, each time with szB=128. What happens in your
> case?
> >
> >  When vgPlain_machine_ppc32_set_clszB() is invoked for the first time, at
> entry time:
> >  Is vai.ppc_cache_line_szB == 0? What is the value of szB?
> >
> >  Is vgPlain_machine_ppc32_set_clszB() invoked more than once? What value
> does
> >  vai.ppc_cache_line_szB hold each time? What value does szB hold each
> time?
> >
> >  Essentially, why does: vai.ppc_cache_line_szB == 0 ||
> vai.ppc_cache_line_szB == szB fail?
> >  Either at the first invocation vai.ppc_cache_line_szB != 0 or at a
> subsequent invocation,
> >  szB changes what already exists in vai.ppc_cache_line_szB - why?
> >
> >  One other try: Likely, you are compiling Valgrind optimized by default.
> What if you compile
> >  it with optimization turned off: make CFLAGS="-O0 -g"? Does the assert
> still happen?
> >
> > Regards,
> > Anmol.
> >
> > anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> gdb bin/valgrind
> > GNU gdb (GDB) Fedora (7.3.50.20110722-9.fc16)
> > Copyright (C) 2011 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "ppc64-redhat-linux-gnu".
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>...
> > Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
> 3.8.1/bin/valgrind...done.
> > (gdb) add-inferior -exec lib/valgrind/memcheck-ppc64-linux
> > Added inferior 2
> > Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
> 3.8.1/lib/valgrind/memcheck-ppc64-linux...done.
> > (gdb) inferior 2
> > [Switching to inferior 2 [process 0]
> (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-
> ppc64-linux)]
> > (gdb) break vgPlain_machine_ppc64_set_clszB
> > Breakpoint 1 at 0x38078354: file m_machine.c, line 1465.
> > (gdb) inferior 1
> > [Switching to inferior 1 [process 0]
> (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind)]
> > (gdb) run ~/hello
> > Starting program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
> 3.8.1/bin/valgrind ~/hello
> > process 7757 is executing new program:
> /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-
> ppc64-linux
> > Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-
> 24.fc16.7.ppc64
> >
> > Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at
> m_machine.c:1465
> > 1465    {
> > (gdb) bt
> > #0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
> > #1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized
> out>,
> > clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8,
> orig_envp=0x402010260, init_sp=0xfffffffeec0)
> >     at m_initimg/initimg-linux.c:725
> > #2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
> > #3  0x000000003807b748 in valgrind_main (argc=<optimized out>,
> argv=0xfffffffeec8,
> > envp=0xfffffffeee0) at m_main.c:1852
> > #4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at
> m_main.c:2994
> > #5  0x0000000038078608 in ._start ()
> > (gdb) c
> > Continuing.
> >
> > Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at
> m_machine.c:1465
> > 1465    {
> > (gdb) bt
> > #0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
> > #1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized
> out>,
> > clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8,
> orig_envp=0x402010260, init_sp=0xfffffffeec0)
> >     at m_initimg/initimg-linux.c:725
> > #2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
> > #3  0x000000003807b748 in valgrind_main (argc=<optimized out>,
> argv=0xfffffffeec8,
> > envp=0xfffffffeee0) at m_main.c:1852
> > #4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at
> m_main.c:2994
> > #5  0x0000000038078608 in ._start ()
> > (gdb) c
> > Continuing.
> > ==7822== Memcheck, a memory error detector
> > ==7822== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> > ==7822== Using Valgrind-3.8.1-FSL-SDK-1.4-spe-Fri-May-24-080638-PDT-2013
> and LibVEX; rerun with
> > -h for copyright info
> > ==7822== Command: /home/anmol/hello
> > ==7822==
> > ==7822== Invalid write of size 4
> > ==7822==    at 0x10000540: main (hello.c:8)
> > ==7822==  Address 0x4040044 is 0 bytes after a block of size 4 alloc'd
> > ==7822==    at 0x40281FC: malloc (vg_replace_malloc.c:270)
> > ==7822==    by 0x10000523: main (hello.c:6)
> > ==7822==
> > ==7822==
> > ==7822== HEAP SUMMARY:
> > ==7822==     in use at exit: 4 bytes in 1 blocks
> > ==7822==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
> > ==7822==
> > ==7822== LEAK SUMMARY:
> > ==7822==    definitely lost: 4 bytes in 1 blocks
> > ==7822==    indirectly lost: 0 bytes in 0 blocks
> > ==7822==      possibly lost: 0 bytes in 0 blocks
> > ==7822==    still reachable: 0 bytes in 0 blocks
> > ==7822==         suppressed: 0 bytes in 0 blocks
> > ==7822== Rerun with --leak-check=full to see details of leaked memory
> > ==7822==
> > ==7822== For counts of detected and suppressed errors, rerun with: -v
> > ==7822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> > [Inferior 1 (process 7822) exited normally]
> > (gdb)
> >
> 
> Hi Anmol,
> 
> I could not try GDB session as you suggested below. Unfortunately add-
> inferior command is not supported on our installation. I tried to put
> printf
> in the code but that gave vague errors. Next I tried to put some asserts at
> the same place like:
> 
> 1. vg_assert(vai.ppc_cache_line_szB == 0)
> 2. vg_assert(vai.ppc_cache_line_szB == szB)
> 3. vg_assert(szB != 0)
> 4. vg_assert(szB != 32)
> 5. vg_assert(szB != 64)
> 6. vg_assert(szB != 128)
> 
> The test failed again at line (2) above. Will this information help? Do you
> want me to try something else?
> 
> Warm Regards,
> Vishal

Hi Vishal,

 How about the other experiment where you build Valgrind with the default optimization
 level turned off? i.e. start over (do a: make clean) and then do a: make CFLAGS="-O0 -g" 

 Also, I tried the following out:

----
anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> git diff coregrind/m_machine.c
diff --git a/coregrind/m_machine.c b/coregrind/m_machine.c
index 6a77057..122674a 100644
--- a/coregrind/m_machine.c
+++ b/coregrind/m_machine.c
@@ -1465,6 +1465,8 @@ void VG_(machine_ppc64_set_clszB)( Int szB )
 {
    vg_assert(hwcaps_done);

+   VG_(printf)("\nmachine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: %d, szB: %d)\n", vai.ppc_cache_line_szB, szB);
+
    /* Either the value must not have been set yet (zero) or we can
       tolerate it being set to the same value multiple times, as the
       stack scanning logic in m_main is a bit stupid. */
@@ -1473,6 +1475,7 @@ void VG_(machine_ppc64_set_clszB)( Int szB )

    vg_assert(szB == 32 || szB == 64 || szB == 128);
    vai.ppc_cache_line_szB = szB;
+   VG_(printf)("\nmachine_ppc64_set_clszB() (pre-exit)/(vai.ppc_cache_line_szB: %d, szB: %d)\n", vai.ppc_cache_line_szB, szB);
 }
anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> ./bin/valgrind --leak-check=full ~/hello

machine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: 0, szB: 128)

machine_ppc64_set_clszB() (pre-exit)/(vai.ppc_cache_line_szB: 128, szB: 128)

machine_ppc64_set_clszB() (post-entry)/(vai.ppc_cache_line_szB: 128, szB: 128)

machine_ppc64_set_clszB() (pre-exit)/(vai.ppc_cache_line_szB: 128, szB: 128)

/* Usual Valgrind output... */
anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1>
----

 If you could do the similar experiment for your Valgrind, we'll learn something about what is going on.

Regards,
Anmol.

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Vishal <vis...@gm...>]

> 
> Hi Vishal,
> 
>  I do not have a PPC476 FP system, so I cannot attempt to reproduce the 
issue.
>  But, we need to understand what is going on. I tried this on the IBM 
POWER 7
>  system I have here at work (see log below). Please could you try the 
corresponding
>  debug session on your PPC476 FP system?
> 
>  Note the comment in the code: "Either the value must not have been set 
yet (zero) or we can
>  tolerate it being set to the same value multiple times, ..." In the log 
below,
>  we see that vgPlain_machine_ppc64_set_clszB() is invoked twice before
>  Valgrind/memcheck exits, each time with szB=128. What happens in your 
case?
> 
>  When vgPlain_machine_ppc32_set_clszB() is invoked for the first time, at 
entry time:
>  Is vai.ppc_cache_line_szB == 0? What is the value of szB?
> 
>  Is vgPlain_machine_ppc32_set_clszB() invoked more than once? What value 
does
>  vai.ppc_cache_line_szB hold each time? What value does szB hold each 
time? 
> 
>  Essentially, why does: vai.ppc_cache_line_szB == 0 || 
vai.ppc_cache_line_szB == szB fail?
>  Either at the first invocation vai.ppc_cache_line_szB != 0 or at a 
subsequent invocation,
>  szB changes what already exists in vai.ppc_cache_line_szB - why?
> 
>  One other try: Likely, you are compiling Valgrind optimized by default. 
What if you compile
>  it with optimization turned off: make CFLAGS="-O0 -g"? Does the assert 
still happen?
> 
> Regards,
> Anmol.
> 
> anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> gdb bin/valgrind
> GNU gdb (GDB) Fedora (7.3.50.20110722-9.fc16)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "ppc64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
3.8.1/bin/valgrind...done.
> (gdb) add-inferior -exec lib/valgrind/memcheck-ppc64-linux
> Added inferior 2
> Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
3.8.1/lib/valgrind/memcheck-ppc64-linux...done.
> (gdb) inferior 2
> [Switching to inferior 2 [process 0] 
(/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-
ppc64-linux)]
> (gdb) break vgPlain_machine_ppc64_set_clszB
> Breakpoint 1 at 0x38078354: file m_machine.c, line 1465.
> (gdb) inferior 1
> [Switching to inferior 1 [process 0] 
(/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind)]
> (gdb) run ~/hello 
> Starting program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-
3.8.1/bin/valgrind ~/hello
> process 7757 is executing new program: 
/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-
ppc64-linux
> Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-
24.fc16.7.ppc64
> 
> Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at 
m_machine.c:1465
> 1465    {
> (gdb) bt
> #0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
> #1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized 
out>,
> clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8, 
orig_envp=0x402010260, init_sp=0xfffffffeec0)
>     at m_initimg/initimg-linux.c:725
> #2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
> #3  0x000000003807b748 in valgrind_main (argc=<optimized out>, 
argv=0xfffffffeec8,
> envp=0xfffffffeee0) at m_main.c:1852
> #4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at 
m_main.c:2994
> #5  0x0000000038078608 in ._start ()
> (gdb) c
> Continuing.
> 
> Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at 
m_machine.c:1465
> 1465    {
> (gdb) bt
> #0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
> #1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized 
out>,
> clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8, 
orig_envp=0x402010260, init_sp=0xfffffffeec0)
>     at m_initimg/initimg-linux.c:725
> #2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
> #3  0x000000003807b748 in valgrind_main (argc=<optimized out>, 
argv=0xfffffffeec8,
> envp=0xfffffffeee0) at m_main.c:1852
> #4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at 
m_main.c:2994
> #5  0x0000000038078608 in ._start ()
> (gdb) c
> Continuing.
> ==7822== Memcheck, a memory error detector
> ==7822== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==7822== Using Valgrind-3.8.1-FSL-SDK-1.4-spe-Fri-May-24-080638-PDT-2013 
and LibVEX; rerun with
> -h for copyright info
> ==7822== Command: /home/anmol/hello
> ==7822==
> ==7822== Invalid write of size 4
> ==7822==    at 0x10000540: main (hello.c:8)
> ==7822==  Address 0x4040044 is 0 bytes after a block of size 4 alloc'd
> ==7822==    at 0x40281FC: malloc (vg_replace_malloc.c:270)
> ==7822==    by 0x10000523: main (hello.c:6)
> ==7822==
> ==7822==
> ==7822== HEAP SUMMARY:
> ==7822==     in use at exit: 4 bytes in 1 blocks
> ==7822==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
> ==7822==
> ==7822== LEAK SUMMARY:
> ==7822==    definitely lost: 4 bytes in 1 blocks
> ==7822==    indirectly lost: 0 bytes in 0 blocks
> ==7822==      possibly lost: 0 bytes in 0 blocks
> ==7822==    still reachable: 0 bytes in 0 blocks
> ==7822==         suppressed: 0 bytes in 0 blocks
> ==7822== Rerun with --leak-check=full to see details of leaked memory
> ==7822==
> ==7822== For counts of detected and suppressed errors, rerun with: -v
> ==7822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> [Inferior 1 (process 7822) exited normally]
> (gdb)
> 

Hi Anmol,

I could not try GDB session as you suggested below. Unfortunately add-
inferior command is not supported on our installation. I tried to put printf 
in the code but that gave vague errors. Next I tried to put some asserts at 
the same place like:

1. vg_assert(vai.ppc_cache_line_szB == 0)
2. vg_assert(vai.ppc_cache_line_szB == szB)
3. vg_assert(szB != 0)
4. vg_assert(szB != 32)
5. vg_assert(szB != 64)
6. vg_assert(szB != 128)

The test failed again at line (2) above. Will this information help? Do you 
want me to try something else?

Warm Regards,
Vishal

Re: [Valgrind-users] Valgrind shows "Invalid write os size 4" for memory allocated for the stack

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

On Wed, 2013-07-24 at 22:08 +0200, Philippe Waroquiers wrote:

> At this moment, the hypothesis is that if the stack memory is
> managed by the user, then when the thread terminates, the stack memory
> is not marked by memcheck as addressible again.
> I need to investigate more in depth to confirm this hypothesis.
Investigations have confirmed the hyposthesis and have lead to
https://bugs.kde.org/show_bug.cgi?id=323020
which summarises/collects several strange aspects of thread stack
handling.

At this point, the only possible fix I see is to add a valgrind client
request in your code to mark the released stack as accessible.

No clear way how this can be done automatically by valgrind, without
introducing the risk of more false positive and/or false negative.

Philippe

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Paralkar Anmol-B. <B0...@fr...>]

> -----Original Message-----
> From: Vishal [mailto:vis...@gm...]
> Sent: Tuesday, July 30, 2013 1:05 AM
> To: val...@li...
> Subject: Re: [Valgrind-users] Valgrind throws assertion on powerpc while
> trying to run 'ls'
> 
> Paralkar Anmol-B07584 <B07584 <at> freescale.com> writes:
> 
> >
> > > -----Original Message-----
> > > From: Vishal [mailto:vishal.ajmera <at> gmail.com]
> > > Sent: Monday, July 29, 2013 1:40 PM
> > > To: valgrind-users <at> lists.sourceforge.net
> > > Subject: [Valgrind-users] Valgrind throws assertion on powerpc while
> trying
> > > to run 'ls'
> > >
> > > Hi,
> > >
> > > I am using valgrind 3.8.1 on powerpc. I could compile the valgrind
> > > successfully however problem is when I try to run valgrind with any
> command
> > > I
> > > get following error:
> > >
> > > $ valgrind ls
> > >
> > > valgrind: m_machine.c:1381 (vgPlain_machine_ppc32_set_clszB): Assertion
> > > 'vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB' failed.
> > >
> > > Can someone help me in correcting above problem? Is my installation
> > > correct?
> > >
> > > Warm Regards,
> > > Vishal
> >
> > Hi Vishal,
> >
> >  What platform (PowerPC variant) are you on?
> >
> >  There is an entry in Valgrind's KDE Bugtracking System:
> >
> >    https://bugs.kde.org/show_bug.cgi?id=308135
> >
> >  - just in case it is relevant or it helps.
> >
> > Thanks,
> > Anmol.
> >
> 
> Hi Anmol,
> 
> I am using PPC476 FP variant. I looked at the bug posting but the assert
> error mentioned in posting is at a different line then where I am getting
> it
> and so wondering if I had configured valgrind correctly.
> 
>    vg_assert(vai.ppc_cache_line_szB == 0
>              || vai.ppc_cache_line_szB == szB); -- I get error at this
> line.
> 
> 
>   vg_assert(szB == 32 || szB == 64 || szB == 128); -- posting in bugzilla
> is
> for this line.
> 
> The two lines above are in the same function in m_machine.c one after
> other.
> 
> Note: when I comment the above line, compilation goes without error and I
> could run valgrind. Is it safe to comment the above line which is giving
> error?
> 
> Warm Regards,
> Vishal

Hi Vishal,

 I do not have a PPC476 FP system, so I cannot attempt to reproduce the issue.
 But, we need to understand what is going on. I tried this on the IBM POWER 7
 system I have here at work (see log below). Please could you try the corresponding
 debug session on your PPC476 FP system?

 Note the comment in the code: "Either the value must not have been set yet (zero) or we can
 tolerate it being set to the same value multiple times, ..." In the log below,
 we see that vgPlain_machine_ppc64_set_clszB() is invoked twice before
 Valgrind/memcheck exits, each time with szB=128. What happens in your case?

 When vgPlain_machine_ppc32_set_clszB() is invoked for the first time, at entry time:
 Is vai.ppc_cache_line_szB == 0? What is the value of szB?

 Is vgPlain_machine_ppc32_set_clszB() invoked more than once? What value does
 vai.ppc_cache_line_szB hold each time? What value does szB hold each time? 

 Essentially, why does: vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB fail?
 Either at the first invocation vai.ppc_cache_line_szB != 0 or at a subsequent invocation,
 szB changes what already exists in vai.ppc_cache_line_szB - why?

 One other try: Likely, you are compiling Valgrind optimized by default. What if you compile
 it with optimization turned off: make CFLAGS="-O0 -g"? Does the assert still happen?

Regards,
Anmol.

anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> gdb bin/valgrind
GNU gdb (GDB) Fedora (7.3.50.20110722-9.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind...done.
(gdb) add-inferior -exec lib/valgrind/memcheck-ppc64-linux
Added inferior 2
Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-ppc64-linux...done.
(gdb) inferior 2
[Switching to inferior 2 [process 0] (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-ppc64-linux)]
(gdb) break vgPlain_machine_ppc64_set_clszB
Breakpoint 1 at 0x38078354: file m_machine.c, line 1465.
(gdb) inferior 1
[Switching to inferior 1 [process 0] (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind)]
(gdb) run ~/hello 
Starting program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind ~/hello
process 7757 is executing new program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-ppc64-linux
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-24.fc16.7.ppc64

Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
1465    {
(gdb) bt
#0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
#1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized out>, clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8, orig_envp=0x402010260, init_sp=0xfffffffeec0)
    at m_initimg/initimg-linux.c:725
#2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
#3  0x000000003807b748 in valgrind_main (argc=<optimized out>, argv=0xfffffffeec8, envp=0xfffffffeee0) at m_main.c:1852
#4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at m_main.c:2994
#5  0x0000000038078608 in ._start ()
(gdb) c
Continuing.

Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
1465    {
(gdb) bt
#0  vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465
#1  0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized out>, clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8, orig_envp=0x402010260, init_sp=0xfffffffeec0)
    at m_initimg/initimg-linux.c:725
#2  vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930
#3  0x000000003807b748 in valgrind_main (argc=<optimized out>, argv=0xfffffffeec8, envp=0xfffffffeee0) at m_main.c:1852
#4  0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at m_main.c:2994
#5  0x0000000038078608 in ._start ()
(gdb) c
Continuing.
==7822== Memcheck, a memory error detector
==7822== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7822== Using Valgrind-3.8.1-FSL-SDK-1.4-spe-Fri-May-24-080638-PDT-2013 and LibVEX; rerun with -h for copyright info
==7822== Command: /home/anmol/hello
==7822==
==7822== Invalid write of size 4
==7822==    at 0x10000540: main (hello.c:8)
==7822==  Address 0x4040044 is 0 bytes after a block of size 4 alloc'd
==7822==    at 0x40281FC: malloc (vg_replace_malloc.c:270)
==7822==    by 0x10000523: main (hello.c:6)
==7822==
==7822==
==7822== HEAP SUMMARY:
==7822==     in use at exit: 4 bytes in 1 blocks
==7822==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==7822==
==7822== LEAK SUMMARY:
==7822==    definitely lost: 4 bytes in 1 blocks
==7822==    indirectly lost: 0 bytes in 0 blocks
==7822==      possibly lost: 0 bytes in 0 blocks
==7822==    still reachable: 0 bytes in 0 blocks
==7822==         suppressed: 0 bytes in 0 blocks
==7822== Rerun with --leak-check=full to see details of leaked memory
==7822==
==7822== For counts of detected and suppressed errors, rerun with: -v
==7822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
[Inferior 1 (process 7822) exited normally]
(gdb)
 

[Valgrind-users] Using Valgrind on an Embedded project

[Emil D. <ler...@gm...>]

Hi,


Currently I am working on an Embedded Project. I am using IAR Embedded
Workbench IDE and target platform is 8051-based microcontroller. Is it
possible to use Valgrind tool to check the code I wrote?

Thanks,
Emil

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Vishal <vis...@gm...>]

Paralkar Anmol-B07584 <B07584 <at> freescale.com> writes:

> 
> > -----Original Message-----
> > From: Vishal [mailto:vishal.ajmera <at> gmail.com]
> > Sent: Monday, July 29, 2013 1:40 PM
> > To: valgrind-users <at> lists.sourceforge.net
> > Subject: [Valgrind-users] Valgrind throws assertion on powerpc while 
trying
> > to run 'ls'
> > 
> > Hi,
> > 
> > I am using valgrind 3.8.1 on powerpc. I could compile the valgrind
> > successfully however problem is when I try to run valgrind with any 
command
> > I
> > get following error:
> > 
> > $ valgrind ls
> > 
> > valgrind: m_machine.c:1381 (vgPlain_machine_ppc32_set_clszB): Assertion
> > 'vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB' failed.
> > 
> > Can someone help me in correcting above problem? Is my installation
> > correct?
> > 
> > Warm Regards,
> > Vishal
> 
> Hi Vishal,
> 
>  What platform (PowerPC variant) are you on?
> 
>  There is an entry in Valgrind's KDE Bugtracking System:
> 
>    https://bugs.kde.org/show_bug.cgi?id=308135
> 
>  - just in case it is relevant or it helps.
> 
> Thanks,
> Anmol.
> 

Hi Anmol,

I am using PPC476 FP variant. I looked at the bug posting but the assert 
error mentioned in posting is at a different line then where I am getting it 
and so wondering if I had configured valgrind correctly.

   vg_assert(vai.ppc_cache_line_szB == 0
             || vai.ppc_cache_line_szB == szB); -- I get error at this line.

   
  vg_assert(szB == 32 || szB == 64 || szB == 128); -- posting in bugzilla is 
for this line.

The two lines above are in the same function in m_machine.c one after other.

Note: when I comment the above line, compilation goes without error and I 
could run valgrind. Is it safe to comment the above line which is giving 
error?

Warm Regards,
Vishal

Re: [Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Paralkar Anmol-B. <B0...@fr...>]

> -----Original Message-----
> From: Vishal [mailto:vis...@gm...]
> Sent: Monday, July 29, 2013 1:40 PM
> To: val...@li...
> Subject: [Valgrind-users] Valgrind throws assertion on powerpc while trying
> to run 'ls'
> 
> Hi,
> 
> I am using valgrind 3.8.1 on powerpc. I could compile the valgrind
> successfully however problem is when I try to run valgrind with any command
> I
> get following error:
> 
> $ valgrind ls
> 
> valgrind: m_machine.c:1381 (vgPlain_machine_ppc32_set_clszB): Assertion
> 'vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB' failed.
> 
> Can someone help me in correcting above problem? Is my installation
> correct?
> 
> Warm Regards,
> Vishal

Hi Vishal,

 What platform (PowerPC variant) are you on?

 There is an entry in Valgrind's KDE Bugtracking System:

   https://bugs.kde.org/show_bug.cgi?id=308135
 
 - just in case it is relevant or it helps.

Thanks,
Anmol.

[Valgrind-users] Valgrind throws assertion on powerpc while trying to run 'ls'

[Vishal <vis...@gm...>]

Hi,

I am using valgrind 3.8.1 on powerpc. I could compile the valgrind 
successfully however problem is when I try to run valgrind with any command I 
get following error:

$ valgrind ls

valgrind: m_machine.c:1381 (vgPlain_machine_ppc32_set_clszB): Assertion 
'vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB' failed.

Can someone help me in correcting above problem? Is my installation correct?

Warm Regards,
Vishal

Re: [Valgrind-users] time-stamp of memory allocation

[willpz <zie...@gm...>]

Hi Robin,

Thank you for your answer. Instead of using a timestamp to compare logs, I
put a client request (VALGRIND_DO_LEAK_CHECK or
VALGRIND_DO_CHANGED_LEAK_CHECK) in my code as Philippe suggested, so I can
run the test and then call the leak check.

Best Regards,
Willian

Re: [Valgrind-users] time-stamp of memory allocation

[Robin R. <rob...@sa...>]

willpz <zielonca <at> gmail.com> writes:

> 
> > 
> > Thank you,
> > that fixed it!
> > 
> > Robin
> > 
> > 
----------------------------------------------------------------------------
--
> > Free Next-Gen Firewall Hardware Offer
> > Buy your Sophos next-gen firewall before the end March 2013 
> > and get the hardware for free! Learn more.
> > http://p.sf.net/sfu/sophos-d2d-feb
> > 
> 
> Hi,
> 
> Could you please tell how did you solve this issue (and eventually post 
the
> patch here)? 
> 
> Willian
> 
> Rehrmann, Robin <robin.rehrmann <at> sap.com> writes:
> 
> 
----------------------------------------------------------------------------
--
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/
ostg.clktrk
> 

Hi,
I have not done it via patch. I just used vgdb:

VALGRIND=`which valgrind`
OPT="-v --tool=memcheck --leak-check=full --error-limit=no --log-file=
$LOG_FILE --undef-value-errors=no --num-callers=32 --fullpath-after=src/ --
vgdb=yes --gen-suppressions=all"

$VALGRIND $OPT <prog> &
back_pid=$!
vgdb --pid=$back_pid leak_check full definiteleak >> $log_file

Regards, 

Robin

[Valgrind-users] Show more callstacks for MemoryPool related errors

[Matthias S. <zz...@ge...>]

Hi there!

As the new valgrind can show alloc and free callstack for use after free 
of normal heap memory I thought this should also work for memory pools.
There are even more callstacks that are known.

See https://bugs.kde.org/show_bug.cgi?id=322256

For the testcase clireq_nofill.c

Before:

==26295== Invalid read of size 1
==26295==    at 0x8048780: main (clireq_nofill.c:23)
==26295==  Address 0x4034028 is 0 bytes inside a recently re-allocated block of size 40 alloc'd
==26295==    at 0x4009D98: malloc (vg_replace_malloc.c:270)
==26295==    by 0x804860E: main (clireq_nofill.c:16)
==26295==

After:
==26693== Invalid read of size 1
==26693==    at 0x8048780: main (clireq_nofill.c:23)
==26693==  Address 0x4034028 is 0 bytes inside a recently re-allocated block of size 40 alloc'd
==26693==    at 0x40093A1: malloc (vg_replace_malloc.c:291)
==26693==    by 0x804860E: main (clireq_nofill.c:16)
==26693==   inner block was freed at
==26693==    at 0x804876B: main (clireq_nofill.c:22)
==26693==   inner block was allocated at
==26693==    at 0x80486E0: main (clireq_nofill.c:20)

For this I only wonder about how to name the different callstacks.


Regards
Matthias

[Valgrind-users] [PATCH] Fix vgcore file to show the crashed thread

[Matthias S. <zz...@ge...>]

Hi there!

I changed writing of vgcore to make it obvious which thread has crashed.
This is done by moving the thread info for the crashing thread to be the 
first.

See https://bugs.kde.org/show_bug.cgi?id=315199

If thread 5 crashed, gdb opening vgcore still shows thread 1 as active.
After my change, thread 5 is the active one.

Question: How to create a test for this?
My naive idea: The test needs to run valgrind until the client app crashes,
and then open vgcore in gdb to issue "bt" and check if this is the 
correct callstack.

Regards
Matthias

Re: [Valgrind-users] Thread names in valgrind and vgdb

[Matthias S. <zz...@ge...>]

On 07.11.2012 16:54, Matthias Schwarzott wrote:
> Hi!
>
> I wonder if it would be good to have valgrind remember the names of the
> threads.
> Our application sets the name of the threads using
I finally managed to create a ticket with the current version of the 
patch attached:

https://bugs.kde.org/show_bug.cgi?id=322254

Remaining open issues:
* The thread info tid+name is not printed if it is still the same thread 
but the name changed.
* The thread info is not printed if it is a different thread, but the 
tid is the same (see https://bugs.kde.org/show_bug.cgi?id=322258).
* The first thread is called "main", but it could get the name of the 
real executable (as without valgrind).
* The gdb test stdout filter does not like the changed output of "info 
threads".
* For drd/helgrind, copy the name over to the thread structures of the 
tool (to also keep it after a thread has terminated).

Regards
Matthias

Re: [Valgrind-users] time-stamp of memory allocation

[willpz <zie...@gm...>]

> 
> Thank you,
> that fixed it!
> 
> Robin
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> 


Hi,

Could you please tell how did you solve this issue (and eventually post the
patch here)? 

Willian

Rehrmann, Robin <robin.rehrmann <at> sap.com> writes:

Re: [Valgrind-users] Valgrind shows "Invalid write os size 4" for memory allocated for the stack

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

On Wed, 2013-07-24 at 14:05 +0000, Masha Naret (mnaret) wrote:
> Hello,
> 
> Could anyone please comment the issue described below:
> Valgrind shows "invalid write" for memory allocated on the stack while the program runs normally.
> I've attached a reproducer for this problem,
Thanks for the reproducer, I started looking at this problem
(limited time permitting :) some days ago.
Stack management in valgrind is somewhat tricky (see e.g. revision
r13467: fix 321960 pthread_create() then alloca() causing invalid stack write errors).
However, r13647 does not fix your specific case.
(you might however try the last SVN version on your full application).

At this moment, the hypothesis is that if the stack memory is
managed by the user, then when the thread terminates, the stack memory
is not marked by memcheck as addressible again.
I need to investigate more in depth to confirm this hypothesis.

Philippe

Re: [Valgrind-users] Valgrind shows "Invalid write os size 4" for memory allocated for the stack

[Masha N. (mnaret) <mn...@ci...>]

Hello,

Could anyone please comment the issue described below:
Valgrind shows "invalid write" for memory allocated on the stack while the program runs normally.
I've attached a reproducer for this problem,
During the run two errors show in valgrind.log,
However only the second one is relevant (is the same as the one I have in code)

There are more details in my previous posts on this subject.
Attching once again

Thank you in advance,
Masha.

-----Original Message-----
From: Masha Naret (mnaret) 
Sent: Wednesday, July 17, 2013 12:10 PM
To: 'Philippe Waroquiers'; 'lop...@gm...'
Cc: 'val...@li...'; Yanai, Omer (OY...@nd...)
Subject: RE: [Valgrind-users] Valgrind shows "Invalid write os size 4" for memory allocated for the stack

Hello,
Attaching the reproducer - please compile it with gcc -g tmpthread.c -o tmpthread -lpthread And then run: tmpthread argsFile Also attached argsFile and valgrind log.

There are two "Invalid write" errors in the log, but only the second one seems to be the same as in the original program.

Some more explanation:
In the original program I noticed valgrind reported the problem when the stack, while growing, grew from area with permissions 'rwx' to area with permissions 'rw'.
The difference in premissions happened since each time thread stack is created, it's lower and upper part are protected with mprotect(NONE) and when it's out of use the protection is set back to READ | WRITE.
(exactly as in reproducer)
However, when running the program with valgrind, for some reason initially the all the momery is set to 'rwx'.
Which is weird, since normally the memory for the stack shouldn't have the 'x' permission.
When running the program without valgrind, there's no memory with 'rwx', only 'rw'

If I modify the original program to restore also EXEC persmission, valgrind doesn't report any error, however this doesn't seem like a correct thing to do.
The same happens with the reproducer.
If you modify the code of the function restoring permissions to add PROT_EXEC persmissions :

static void ReleaseThreadStack(int stacksize, void** stackbase) {
    int ret = 0;
    void* ptStack = NULL;

    //remove protection
    ptStack = *stackbase - STACK_GUARD_SIZE;
    ret = mprotect(ptStack, STACK_GUARD_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC );
    ptStack = *stackbase + stacksize;
    ret = mprotect(ptStack, STACK_GUARD_SIZE, PROT_READ | PROT_WRITE  | PROT_EXEC);

    return;
}

The second "invalid write" problem will disappear!

If there’s need of any further logs, please let me know, I’ll send you valgrind debugger outputs.

Thank you very much for your support,
Masha.

-----Original Message-----
From: Philippe Waroquiers [mailto:phi...@sk...]
Sent: Wednesday, June 12, 2013 10:44 PM
To: Masha Naret (mnaret)
Cc: val...@li...
Subject: Re: [Valgrind-users] Valgrind shows "Invalid write os size 4" for memory allocated for the stack

On Mon, 2013-06-10 at 01:23 -0700, mnaret wrote:
> Hello,
> Recently I'm getting lot's of "invalid read/invalid write" valgrind 
> errors which point out at memory allocated for the stack. However the 
> code doesn't crush and finish running successfully.
> I'm trying to understand where the error comes from - and will be 
> grateful fo any help wih this issue.
Do you have a small (compilable) reproducer ?
Philippe

Re: [Valgrind-users] Time relation between errors in xml format and stdout/stderr

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

On Tue, 2013-07-23 at 12:24 +0200, Matthias Schwarzott wrote:
> Hi,
> 
> I am running a larger test-application under valgrind. It prints start 
> and end of testcases to stderr.
> Using the text output I immediately see to which testcase an error belongs.
> Now is the point I want to get some numbers about valgrind errors extracted.
> For this xml is the type of output to use.
Maybe you could use the valgrind request VALGRIND_COUNT_ERRORS
and output the nr of reported errors from your program on stderr,
and use this to retrive in the xml file the errors reported by
a specific test ?

> 
> I wonder if it is possible to get the errors xml-format and still know 
> the relation to the stderr output.
> 
> These are my thoughts:
> 1. Enable text and xml error output the same time.
> 2. Print a reference to the xml error-id onto stderr.
> 3. Using "--xml=yes --xml-fd=2" and splitting it later (maybe add some 
> prefix to these lines).
> 
> What do you think about this?
> 
> Regards
> Matthias
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Time relation between errors in xml format and stdout/stderr

[Matthias S. <zz...@ge...>]

Hi,

I am running a larger test-application under valgrind. It prints start 
and end of testcases to stderr.
Using the text output I immediately see to which testcase an error belongs.
Now is the point I want to get some numbers about valgrind errors extracted.
For this xml is the type of output to use.

I wonder if it is possible to get the errors xml-format and still know 
the relation to the stderr output.

These are my thoughts:
1. Enable text and xml error output the same time.
2. Print a reference to the xml error-id onto stderr.
3. Using "--xml=yes --xml-fd=2" and splitting it later (maybe add some 
prefix to these lines).

What do you think about this?

Regards
Matthias

Re: [Valgrind-users] " outside mapped rw segments" valgrind error

[vijay n. <vi...@gm...>]

Hello Veterans,

I recently upgraded valgrind to 3.8.1 and I see the below error when
my program is valground ?

--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
--30636-- warning: DiCfSI 0x0 .. 0x3 outside mapped rw segments (NONE)
==30636== Warning: N_CIEs is too low.  Increase and recompile. in
DWARF2 CFI reading

Why valgrind prints such a log ?

Re: [Valgrind-users] List of libc functions which are replaced by valgrind?

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

> Is there a list of functions which are replaced by valgrind's own versions?

The code for memcheck is in
  memcheck/mc_replace_strmem.c
  memcheck/mc_malloc_wrappers.c
Other tools have different interceptions.

> Are strcpy(), stpcpy() and stpncpy() replaced?

Yes, memcheck replaces all three.

[Valgrind-users] List of libc functions which are replaced by valgrind?

[Irek S. <isz...@gm...>]

Is there a list of functions which are replaced by valgrind's own versions?

Are strcpy(), stpcpy() and stpncpy() replaced?

Irek

Re: [Valgrind-users] Statically compiling Valgrind

[Davis F. <dav...@gm...>]

Thanks John / Tom -- I aim to try that out.  Regards, Davis

On Sun, Jul 21, 2013 at 6:58 PM, John Reiser <jr...@bi...> wrote:

> The top-level Makefile for valgrind looks somewhat ordinary.  So you could
> try
> adding "-static  -static-libgcc" to to CFLAGS.  (Or add "-static" to
> LDFLAGS,
> or add "-Wl,-static" to CFLAGS.)  Then look at the final link command:
> invoke
> 'make' and observe the commands that are displayed on stderr.  In the worst
> case, then run under "strace -f -o strace.out -e trace=execve make ..."
> then
> inspect strace.out to find the actual process command line.  Also look at
> the
> output from ldd, to see how well those attempts worked.  You might also
> look
> one level down at memcheck/Makefile, but CFLAGS etc. from the top-level
> Makefile should propagate to the individual tools such as memcheck.
>