valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Please leave Sorceforge

[Mark W. <ma...@kl...>]

On Sun, May 20, 2018 at 02:44:16PM -0400, Jeffrey Walton wrote:
> When signing up for the newsletter we have to " I agree to receive
> these communications from SourceForge.net...." Requiring me to accept
> spam is very disingenuous.
> 
> Please leave Sorceforge.

We could ask the sourceware overseers to take over the mailinglists.
sourceware used to be very strict about not allowing HTML email.
But I believe they will now strip such HTML attachments instead of
just bouncing them. Are others bothered by the current mailinglist
arrangement? Should we start a discussion about moving to sourceware?
(sourceware is where our current git repository lives)

Cheers,

Mark

Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

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

On Sun, 2018-05-20 at 14:49 -0400, Jeffrey Walton wrote:
> I'm working on Fedora 27 x86_64 from Master trying to sidestep
> https://bugs.kde.org/show_bug.cgi?id=387773.
> 
> I configured Valgrind with the following:
> 
>     PKGCONFIG: /usr/local/lib64/pkgconfig
>      CPPFLAGS: -I/usr/local/include -DNDEBUG
>        CFLAGS: -g2 -O2 -m64 -march=native -fPIC
>      CXXFLAGS: -g2 -O2 -m64 -march=native -fPIC
>       LDFLAGS: -L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64
> -Wl,--enable-new-dtags
>        LDLIBS: -ldl -lpthread

Not too sure what you did/how you obtained the above.

The valgrind configure machinery is very special.
Unless you dig into the deep gory details of this machinery,
you should not try to set any variable yourself.
In particular, on dual arch systems (32 and 64 bits), changing
CFLAGS like the above are very likely to give problems.
Also, the valgrind core/tools cannot be linked with any library,
so it is unclear why LDLIBS is set above.

I suggest to start with a very basic configure, e.g.
   ./configure --prefix=<somewhere>
and if that works, then that is a good start :).

If after that, you have problems, you might try to solve them
by playing with configure setup/args/env var, but that is very fragile.

Philippe

Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

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

On 05/20/2018 11:49 AM, Jeffrey Walton wrote:
> I'm working on Fedora 27 x86_64 from Master trying to sidestep
> https://bugs.kde.org/show_bug.cgi?id=387773.
> 
> I configured Valgrind with the following:
> 
>      PKGCONFIG: /usr/local/lib64/pkgconfig
>       CPPFLAGS: -I/usr/local/include -DNDEBUG
>         CFLAGS: -g2 -O2 -m64 -march=native -fPIC
>       CXXFLAGS: -g2 -O2 -m64 -march=native -fPIC
>        LDFLAGS: -L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64
> -Wl,--enable-new-dtags
>         LDLIBS: -ldl -lpthread
> 
> Make'ing results in:
> 
> $ make
> ...
> 
> gcc ... -m32 ... 'priv/main_main.c' ...

> cc1: error: -mpreferred-stack-boundary=2 is not between 3 and 12

This is peculiar: "I am working on ... x86_64" but invoking "gcc -m32"
which requests "generate code for i686".
Also, if the value is not at least 4 then some generated SSE instructions
(even on i686) will fault because they demand 16-byte alignment,
and any call involving a variable number of arguments which includes
any argument that requires 16-byte alignment will generate incorrect code.
The best strategy is to omit "-mpreferred-stack-boudnary" entirely.

[Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

[Jeffrey W. <nol...@gm...>]

I'm working on Fedora 27 x86_64 from Master trying to sidestep
https://bugs.kde.org/show_bug.cgi?id=387773.

I configured Valgrind with the following:

    PKGCONFIG: /usr/local/lib64/pkgconfig
     CPPFLAGS: -I/usr/local/include -DNDEBUG
       CFLAGS: -g2 -O2 -m64 -march=native -fPIC
     CXXFLAGS: -g2 -O2 -m64 -march=native -fPIC
      LDFLAGS: -L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64
-Wl,--enable-new-dtags
       LDLIBS: -ldl -lpthread

Make'ing results in:

$ make
...

gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include
-I../VEX/pub -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1
-DVGPV_x86_linux_vanilla=1 -Ipriv -I/usr/local/include -DNDEBUG -m32
-mpreferred-stack-boundary=2 -O2 -finline-functions -g -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wmissing-parameter-type -Wlogical-op -Wold-style-declaration
-fno-stack-protector -fno-strict-aliasing -fno-builtin
-fomit-frame-pointer  -Wbad-function-cast -fstrict-aliasing -g2 -O2
-m64 -march=native -fPIC -MT priv/libvex_x86_linux_a-main_main.o -MD
-MP -MF priv/.deps/libvex_x86_linux_a-main_main.Tpo -c -o
priv/libvex_x86_linux_a-main_main.o `test -f 'priv/main_main.c' ||
echo './'`priv/main_main.c
cc1: error: -mpreferred-stack-boundary=2 is not between 3 and 12
gmake[3]: *** [Makefile:1907: priv/libvex_x86_linux_a-main_globals.o] Error 1
gmake[3]: *** Waiting for unfinished jobs....
cc1: error: -mpreferred-stack-boundary=2 is not between 3 and 12
gmake[3]: *** [Makefile:1921: priv/libvex_x86_linux_a-main_main.o] Error 1
mv -f priv/.deps/libvex_amd64_linux_a-host_mips_isel.Tpo
priv/.deps/libvex_amd64_linux_a-host_mips_isel.Po

Should we specify -mpreferred-stack-boundary=3 as additional CFLAGS
and CXXFLAGS? Or maybe something else?

Would you like it added to the bug reporter?

Config log is attached.

Jeff

[Valgrind-users] Please leave Sorceforge

[Jeffrey W. <nol...@gm...>]

When signing up for the newsletter we have to " I agree to receive
these communications from SourceForge.net...." Requiring me to accept
spam is very disingenuous.

Please leave Sorceforge.

[Valgrind-users] Kcachegrind data saving feature in tabular format

[fei p. <fei...@gm...>]

For Kcachegrind , How do I save the all callee data in tabular format as in
https://i.imgur.com/itKGHwC.png ?

[Valgrind-users] 答复: [help] I run the pocl , memcheck report this error (the red text), what it meant.

[Wuweijia <wuw...@hu...>]

I re-send the mail against , because the mail  was delivered  failed

-----邮件原件-----
发件人: Wuweijia 
发送时间: 2018年4月19日 13:26
收件人: 'Philippe Waroquiers' <phi...@sk...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: 答复: [Valgrind-users] [help] I run the pocl , memcheck report this error (the red text), what it meant.

How do I check it.

-----邮件原件-----
发件人: Philippe Waroquiers [mailto:phi...@sk...]
发送时间: 2018年4月19日 12:36
收件人: Wuweijia <wuw...@hu...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: Re: [Valgrind-users] [help] I run the pocl , memcheck report this error (the red text), what it meant.

On Thu, 2018-04-19 at 00:39 +0000, Wuweijia wrote:
> memcheck expensive sanity: distinguished_secondaries have changed
>  
> valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240 (vgPlain_sanity_check_general): Assertion 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
>  
> host stacktrace:
> ==4540==    at 0x3803AA8C: show_sched_status_wrk (m_libcassert.c:343) 
> ==4540==    by 0x3803AD07: report_and_quit (m_libcassert.c:419) 
> ==4540==    by 0x3803AD07: vgPlain_assert_fail (m_libcassert.c:485) 
> ==4540==    by 0x3808119B: vgPlain_sanity_check_general
> (scheduler.c:2240) ==4540==    by 0x3808142F: vgPlain_scheduler
> (scheduler.c:1308) ==4540==    by 0x3808E307: thread_wrapper
> (syswrap-linux.c:103) ==4540==    by 0x3808E307: run_a_thread_NORETURN
> (syswrap-linux.c:156) ==4540==    by 0x3808E6CF: 
> vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:325) ==4540== by 
> 0x380B4143: ??? (in /system/lib64/valgrind/memcheck-arm64-linux)
> 
The above is a valgrind self-check/sanity check that detects an internal corruption in its own internal memcheck data structure.
Never seen this assert failing up to now.

This might be 
   * a bug in valgrind itself 
   * (less likely) a nasty bug in your application that succeeded
      to corrupt valgrind memcheck data structures
      Was there any application error reported by Valgrind before this
      failing self-check ?
   * (less likely?) an hardware problem, such as failing memory ?

Philippe

[Valgrind-users] 答复: [help] I run the pocl , memcheck report this error (the red text), what it meant.

[Wuweijia <wuw...@hu...>]

How do I check it.

-----邮件原件-----
发件人: Philippe Waroquiers [mailto:phi...@sk...] 
发送时间: 2018年4月19日 12:36
收件人: Wuweijia <wuw...@hu...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: Re: [Valgrind-users] [help] I run the pocl , memcheck report this error (the red text), what it meant.

On Thu, 2018-04-19 at 00:39 +0000, Wuweijia wrote:
> memcheck expensive sanity: distinguished_secondaries have changed
>  
> valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240 (vgPlain_sanity_check_general): Assertion 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
>  
> host stacktrace:
> ==4540==    at 0x3803AA8C: show_sched_status_wrk (m_libcassert.c:343) 
> ==4540==    by 0x3803AD07: report_and_quit (m_libcassert.c:419) 
> ==4540==    by 0x3803AD07: vgPlain_assert_fail (m_libcassert.c:485) 
> ==4540==    by 0x3808119B: vgPlain_sanity_check_general 
> (scheduler.c:2240) ==4540==    by 0x3808142F: vgPlain_scheduler 
> (scheduler.c:1308) ==4540==    by 0x3808E307: thread_wrapper 
> (syswrap-linux.c:103) ==4540==    by 0x3808E307: run_a_thread_NORETURN 
> (syswrap-linux.c:156) ==4540==    by 0x3808E6CF: 
> vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:325) ==4540==    
> by 0x380B4143: ??? (in /system/lib64/valgrind/memcheck-arm64-linux)
> 
The above is a valgrind self-check/sanity check that detects an internal corruption in its own internal memcheck data structure.
Never seen this assert failing up to now.

This might be 
   * a bug in valgrind itself 
   * (less likely) a nasty bug in your application that succeeded
      to corrupt valgrind memcheck data structures
      Was there any application error reported by Valgrind before this
      failing self-check ?
   * (less likely?) an hardware problem, such as failing memory ?

Philippe

Re: [Valgrind-users] [help] I run the pocl , memcheck report this error (the red text), what it meant.

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

On Thu, 2018-04-19 at 00:39 +0000, Wuweijia wrote:
> memcheck expensive sanity: distinguished_secondaries have changed
>  
> valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240 (vgPlain_sanity_check_general): Assertion 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
>  
> host stacktrace:
> ==4540==    at 0x3803AA8C: show_sched_status_wrk (m_libcassert.c:343)
> ==4540==    by 0x3803AD07: report_and_quit (m_libcassert.c:419)
> ==4540==    by 0x3803AD07: vgPlain_assert_fail (m_libcassert.c:485)
> ==4540==    by 0x3808119B: vgPlain_sanity_check_general (scheduler.c:2240)
> ==4540==    by 0x3808142F: vgPlain_scheduler (scheduler.c:1308)
> ==4540==    by 0x3808E307: thread_wrapper (syswrap-linux.c:103)
> ==4540==    by 0x3808E307: run_a_thread_NORETURN (syswrap-linux.c:156)
> ==4540==    by 0x3808E6CF: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:325)
> ==4540==    by 0x380B4143: ??? (in /system/lib64/valgrind/memcheck-arm64-linux)
> 
The above is a valgrind self-check/sanity check that detects an internal
corruption in its own internal memcheck data structure.
Never seen this assert failing up to now.

This might be 
   * a bug in valgrind itself 
   * (less likely) a nasty bug in your application that succeeded
      to corrupt valgrind memcheck data structures
      Was there any application error reported by Valgrind before this
      failing self-check ?
   * (less likely?) an hardware problem, such as failing memory ?

Philippe

[Valgrind-users] [help] I run the pocl , memcheck report this error (the red text), what it meant.

[Wuweijia <wuw...@hu...>]

[2018-04-15 23:44:37] [HSN_RAW_AP][I] setup_opencl_hdrp : 175 cl_path_name = /system/bin/
pocl_llvm_build_program: Final options: -Dcl_khr_byte_addressable_store -Dcl_khr_global_int32_base_atomics -Dcl_khr_global_int32_extended_atomics -Dcl_khr_local_int32_base_atomics -Dcl_khr_local_int32_extended_atomics -Dcl_khr_spir -Dcl_khr_fp16 -Dcl_khr_int64 -Dcl_khr_fp64 -Dcl_khr_int64_base_atomics -Dcl_khr_int64_extended_atomics  -O0  -x cl -Dinline= -I.  -D__ENDIAN_LITTLE__=1 -D__IMAGE_SUPPORT__=1 -DCL_DEVICE_MAX_GLOBAL_VARIABLE_SIZE=0 -D__OPENCL_VERSION__=200 -cl-std=CL2.0 -D__OPENCL_C_VERSION__=200 -fno-builtin -ffp-contract=off -triple=aarch64-unknown-linux-android -target-cpu generic
### options: -Dcl_khr_byte_addressable_store -Dcl_khr_global_int32_base_atomics -Dcl_khr_global_int32_extended_atomics -Dcl_khr_local_int32_base_atomics -Dcl_khr_local_int32_extended_atomics -Dcl_khr_spir -Dcl_khr_fp16 -Dcl_khr_int64 -Dcl_khr_fp64 -Dcl_khr_int64_base_atomics -Dcl_khr_int64_extended_atomics  -O0  -x cl -Dinline= -I.  -D__ENDIAN_LITTLE__=1 -D__IMAGE_SUPPORT__=1 -DCL_DEVICE_MAX_GLOBAL_VARIABLE_SIZE=0 -D__OPENCL_VERSION__=200 -cl-std=CL2.0 -D__OPENCL_C_VERSION__=200 -fno-builtin -ffp-contract=off -triple=aarch64-unknown-linux-android -target-cpu generic user_options:
memcheck expensive sanity: distinguished_secondaries have changed

valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240 (vgPlain_sanity_check_general): Assertion 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.

host stacktrace:
==4540==    at 0x3803AA8C: show_sched_status_wrk (m_libcassert.c:343)
==4540==    by 0x3803AD07: report_and_quit (m_libcassert.c:419)
==4540==    by 0x3803AD07: vgPlain_assert_fail (m_libcassert.c:485)
==4540==    by 0x3808119B: vgPlain_sanity_check_general (scheduler.c:2240)
==4540==    by 0x3808142F: vgPlain_scheduler (scheduler.c:1308)
==4540==    by 0x3808E307: thread_wrapper (syswrap-linux.c:103)
==4540==    by 0x3808E307: run_a_thread_NORETURN (syswrap-linux.c:156)
==4540==    by 0x3808E6CF: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:325)
==4540==    by 0x380B4143: ??? (in /system/lib64/valgrind/memcheck-arm64-linux)

sched status:
  running_tid=10

Thread 1: status = VgTs_WaitSys (lwpid 4540)

Thread 2: status = VgTs_WaitSys (lwpid 4541)

Thread 3: status = VgTs_WaitSys (lwpid 4543)

Thread 4: status = VgTs_WaitSys (lwpid 4544)

Thread 5: status = VgTs_WaitSys (lwpid 4545)

Thread 6: status = VgTs_WaitSys (lwpid 4546)

Thread 7: status = VgTs_WaitSys (lwpid 4547)

Thread 8: status = VgTs_WaitSys (lwpid 4548)

Thread 9: status = VgTs_WaitSys (lwpid 4549)

Thread 10: status = VgTs_Runnable (lwpid 4550)

Re: [Valgrind-users] Current git fails to compile on macOS

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

On Sat, 2018-04-14 at 13:37 -0400, IMoL wrote:
> Thank you Philippe.
> 
> That patch allows valgrind to compile on macOS.
thanks for the feedback, patch committed as
06cb991bcd9966b614cd672a7d6e26785f60f851

> 
> Still doesn't work for me, mind you, but at least it compiles again :-)
Someone with more Macos knowledge will have to step in ...

Philippe

Re: [Valgrind-users] Current git fails to compile on macOS

[IMoL <im...@gm...>]

Thank you Philippe.

That patch allows valgrind to compile on macOS.

Still doesn't work for me, mind you, but at least it compiles again :-)

- Andy

On Sat, Apr 14, 2018 at 12:24 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Fri, 2018-04-13 at 05:56 -0400, IMoL wrote:
> > git-1f08787cf (of 11 April) fails to build on macOS:
> >
> > m_syswrap/syswrap-generic.c:1797:26: error: variable has incomplete
> type 'struct vki_semid64_ds'
> >    struct vki_semid64_ds buf;
> >                          ^
> > m_syswrap/syswrap-generic.c:1797:11: note: forward declaration of
> 'struct vki_semid64_ds'
> >    struct vki_semid64_ds buf;
> >           ^
> > m_syswrap/syswrap-generic.c:1798:8: error: no member named 'buf64' in
> 'union semun'
> >    arg.buf64 = &buf;
> >    ~~~ ^
> >
> >
> > Looks related to this commit from 1 April (git-54145019b):
> >
> > "n-i-bz Fix possible stack trashing by semctl syscall wrapping"
> Can you try the attached patch ?
> Thanks
> Philippe
>

Re: [Valgrind-users] Current git fails to compile on macOS

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

On Fri, 2018-04-13 at 05:56 -0400, IMoL wrote:
> git-1f08787cf (of 11 April) fails to build on macOS:
> 
> m_syswrap/syswrap-generic.c:1797:26: error: variable has incomplete type 'struct vki_semid64_ds'
>    struct vki_semid64_ds buf;
>                          ^
> m_syswrap/syswrap-generic.c:1797:11: note: forward declaration of 'struct vki_semid64_ds'
>    struct vki_semid64_ds buf;
>           ^
> m_syswrap/syswrap-generic.c:1798:8: error: no member named 'buf64' in 'union semun'
>    arg.buf64 = &buf;
>    ~~~ ^
> 
> 
> Looks related to this commit from 1 April (git-54145019b):
> 
> "n-i-bz Fix possible stack trashing by semctl syscall wrapping" 
Can you try the attached patch ?
Thanks
Philippe

Re: [Valgrind-users] ==10087== Unsupported clone() flags: 0x104011

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

On Fri, 2018-04-13 at 18:27 +0000, Rachel Chen (rychen) wrote:
> Index: third-party/src/valgrind/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c
The release 3.4.1 is from 2009.
I suggest to upgrade to the last release (3.13.0), as it is unlikely
someone will be willing/able to provide support on this very old version.

Since 3.4.1, all this clone flags related code was heavily
restructured/reworked, and supports somewhat more combinations.

So, maybe 3.13.0 will solve your problem.
Feedback welcome ...

Philippe 

[Valgrind-users] ==10087== Unsupported clone() flags: 0x104011

[Rachel C. (rychen) <ry...@ci...>]

Hello,

I encountered the Unsupported clone() error as following:

==10087==
==10087== Unsupported clone() flags: 0x104011
==10087==
==10087== The only supported clone() uses are:
==10087==  - via a threads library (LinuxThreads or NPTL)
==10087==  - via the implementation of fork or vfork
==10087==  - for the Quadrics Elan3 user-space driver
==10087==
==10087== Valgrind detected that your program requires
==10087== the following unimplemented functionality:
==10087==    Valgrind does not support general clone().
==10087== This may be because the functionality is hard to implement,
==10087== or because no reasonable program would behave this way,
==10087== or because nobody has yet needed it.  In any case, let us know at
==10087== www.valgrind.org and/or try to work around the problem, if you can.
==10087==
==10087== Valgrind has to exit now.  Sorry.  Bye!
==10087==

I manually changed syswrap-x86-linux.c with the cloneflag added in the code, but I still get same error. Is there any other workaround for this issue? Here is the code change I have for the file syswrap-x86-linux.c.

Index: third-party/src/valgrind/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c
===================================================================
diff --git a/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c b/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86
-linux.c
index 4838271..f5afdaf 100644
--- a/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c
+++ b/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c
@@ -886,6 +886,7 @@ PRE(sys_clone)
                                   || cloneflags == 0x790F00
                                   || cloneflags == 0x3D0F00
                                   || cloneflags == 0x410F00
+                                  || cloneflags == 0x104011
                                   || cloneflags == 0xF00
                                   || cloneflags == 0xF21)) {
      /* OK */

Appreciate any input on this. Thanks for the help in advance.

Regards,
Rachel

[Valgrind-users] Current git fails to compile on macOS

[IMoL <im...@gm...>]

git-1f08787cf (of 11 April) fails to build on macOS:

m_syswrap/syswrap-generic.c:1797:26: error: variable has incomplete type
'struct vki_semid64_ds'
   struct vki_semid64_ds buf;
                         ^
m_syswrap/syswrap-generic.c:1797:11: note: forward declaration of 'struct
vki_semid64_ds'
   struct vki_semid64_ds buf;
          ^
m_syswrap/syswrap-generic.c:1798:8: error: no member named 'buf64' in
'union semun'
   arg.buf64 = &buf;
   ~~~ ^


Looks related to this commit from 1 April (git-54145019b):

"n-i-bz Fix possible stack trashing by semctl syscall wrapping"

[Valgrind-users] 答复: 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

[Wuweijia <wuw...@hu...>]

Hi John
        You mean I need hide to the symbal operator new   in libc.so ?
         So I trip the libc.so , so there is no symbals operator new in libc.so

localhost:/system/bin # readelf -s  ../lib64/libc++.so | grep Znam
   696: 000000000005cd20    44 FUNC    WEAK   DEFAULT   12 _ZnamRKSt9nothrow_t
   746: 000000000005ce34     4 FUNC    WEAK   DEFAULT   12 _ZnamSt11align_val_t
  1793: 000000000005ce38    44 FUNC    WEAK   DEFAULT   12 _ZnamSt11align_val_tRKSt9
  2089: 000000000005cd1c     4 FUNC    WEAK   DEFAULT   12 _Znam
  4468: 000000000005cd1c     4 FUNC    WEAK   DEFAULT   12 _Znam
  4778: 000000000005cd20    44 FUNC    WEAK   DEFAULT   12 _ZnamRKSt9nothrow_t
  4779: 000000000005ce34     4 FUNC    WEAK   DEFAULT   12 _ZnamSt11align_val_t
  4780: 000000000005ce38    44 FUNC    WEAK   DEFAULT   12 _ZnamSt11align_val_tRKSt9
localhost:/system/bin # readelf -s  ../lib64/libc.so | grep Znam

       So I re-run it , there is no printf for "REDIR to operator new " or " malloc";

     --9071-- REDIR: 0x4b23130 (libc.so:memset) redirected to 0x4c8b2b4 (memset)
--9071-- REDIR: 0x4b6a580 (libc.so:__memcpy_chk) redirected to 0x4c8ba1c (__memcpy_chk)
--9071-- REDIR: 0x4b1fcec (libc.so:malloc) redirected to 0x4c8c168 (malloc)
--9071-- REDIR: 0x4b23710 (libc.so:strlen) redirected to 0x4c8a75c (strlen)
--9071-- REDIR: 0x4b6a514 (libc.so:__strcpy_chk) redirected to 0x4c8b7ac (__strcpy_chk)
--9071-- REDIR: 0x4b2389c (libc.so:strncmp) redirected to 0x4c8a988 (strncmp)
--9071-- REDIR: 0x4b22c70 (libc.so:memcpy) redirected to 0x4c8adc8 (memcpy)
--9071-- REDIR: 0x4b22ab4 (libc.so:memchr) redirected to 0x4c8ab94 (memchr)
--9071-- REDIR: 0x4b1ff38 (libc.so:realloc) redirected to 0x4c8d734 (realloc)
--9071-- REDIR: 0x4b1fbac (libc.so:free) redirected to 0x4c8cdac (free)
--9071-- REDIR: 0x4b22bc0 (libc.so:memcmp) redirected to 0x4c8b02c (bcmp)
--9071-- REDIR: 0x4b23540 (libc.so:strcmp) redirected to 0x4c8ab54 (strcmp)
--9071-- REDIR: 0x4ba8620 (libc.so:strstr) redirected to 0x4c8bbe8 (strstr)
no=0x4ea4d20 n1=0x4ea4d70
--9071-- REDIR: 0x4d03a60 (libc++.so:operator delete[](void*)) redirected to 0x4c8d3c4 (operator delete[](void*))
==9071== Mismatched free() / delete / delete []
==9071==    at 0x4C8D44C: operator delete[](void*) (vg_replace_malloc.c:620)
==9071==    by 0x108797: demoNew (testNew.cpp:16)
==9071==    by 0x108797: main (testNew.cpp:21)
==9071==  Address 0x4ea4d70 is 0 bytes inside a block of size 8 alloc'd
==9071==    at 0x4C8C1F0: malloc (vg_replace_malloc.c:298)
==9071==    by 0x4D15CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)
==9071==    by 0x10876F: demoNew (testNew.cpp:13)
==9071==    by 0x10876F: main (testNew.cpp:21)

Libc++.so is llvm c++, not gnu c++;

Br
Owen

-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2018年4月13日 7:27
收件人: val...@li...
主题: [Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?


> #include <stdio.h>
> #include <stdlib.h>
> 
> class Node{
>    public:
>          int a;
>          int b;
> };
> 
> extern "C" void demoNew(void) {
>          Node *n0 = new Node;
>          Node *n1 = (Node *)new char[sizeof(Node)];
>          printf("no=%p n1=%p\n", n0, n1);
>          delete n0;
>          delete[] n1;
> }
> 
> 
> int main(int argc, char ** argv) {
>          demoNew();
>          return 0;
> }

> --4747-- REDIR: 0x4d9b924 (libc.so:operator new[](unsigned long)) 
> redirected to 0x4c1bb48 (operator new[](unsigned long))

> --4747-- REDIR: 0x4d9b8d8 (libc.so:operator new(unsigned long)) 
> redirected to 0x4c1b7a4 (operator new(unsigned long))

Well, it is puzzling why 'operator new[]' and 'operator new' are in libc.so, the run-time library for *plain*-C.  The C language does not have such functions.

> --4747-- REDIR: 0x4b44a60 (libc++.so:operator delete[](void*)) 
> redirected to 0x4c1c3c4 (operator delete[](void*))

OK, that's the regular 'operator delete[]' for C++.
Where is 'operator delete', the non-array flavor?


> ==4747== Mismatched free() / delete / delete []
> ==4747==    at 0x4C1C44C: operator delete[](void*) (vg_replace_malloc.c:620)
> ==4747==    by 0x108797: demoNew (testNew.cpp:15)
> ==4747==    by 0x108797: main (testNew.cpp:20)
> ==4747==  Address 0x4eb9d70 is 0 bytes inside a block of size 8 alloc'd
> ==4747==    at 0x4C1B1F0: malloc (vg_replace_malloc.c:298)
> ==4747==    by 0x4B56CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)

That reference above to 'operator new(unsigned long)' should have been intercepted directly by valgrind, instead of first calling malloc() [which was intercepted.] Valgrind does not know about "stdlib_new_delete.cpp".  Which shared library is it in?

> ==4747==    by 0x10876F: demoNew (testNew.cpp:12)
> ==4747==    by 0x10876F: main (testNew.cpp:20)
> 
> localhost:/system/bin # nm -C  ../lib64/libc.so  | grep new

> 00000000000b2924 t operator new[](unsigned long)
> 00000000000b28d8 t operator new(unsigned long)

Again, I don't understand why libc.so has those functions.
Does it have also the corresponding 'delete' and 'delete[]'?

> 
> localhost:/system/bin # nm -C  ../lib64/libc++.so  | grep new 
> 000000000005cd1c W operator new[](unsigned long) 000000000005cc8c W 
> operator new(unsigned long)


My working hypothesis is that appearance in libc.so of the code for some C++ operators, instead of appearing only in libc++.so, has confused valgrind.  Also note that the C++ 'operator new'
is a 'W' (weak global) symbol, but the plain-C symbol 'operator new'
is a 't' (strong local) symbol.  A local symbol is not exported, so it is visible only to calls from the same source file.
On the other hand, a weak symbol becomes hidden if there is any [visible] strong definition.  This is very confusing.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] 答复: 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

> #include <stdio.h>
> #include <stdlib.h>
> 
> class Node{
>    public:
>          int a;
>          int b;
> };
> 
> extern "C" void demoNew(void) {
>          Node *n0 = new Node;
>          Node *n1 = (Node *)new char[sizeof(Node)];
>          printf("no=%p n1=%p\n", n0, n1);
>          delete n0;
>          delete[] n1;
> }
> 
> 
> int main(int argc, char ** argv) {
>          demoNew();
>          return 0;
> }

For reference and comparison, on x86_64 Linux with
    g++ (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
    libstdc++-6.4.1-1.fc25.x86_64

the relevant interceptions are
--13225-- REDIR: 0x4ec9a80 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4c2e18e (operator new(unsigned long))
--13225-- REDIR: 0x4ec9b40 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2e87b (operator new[](unsigned long))

--13225-- REDIR: 0x4ec7a70 (libstdc++.so.6:operator delete(void*)) redirected to 0x4c2f1ac (operator delete(void*))
--13225-- REDIR: 0x4ec7aa0 (libstdc++.so.6:operator delete[](void*)) redirected to 0x4c2f67c (operator delete[](void*))

and valgrind does not complain about anything.

[Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

> #include <stdio.h>
> #include <stdlib.h>
> 
> class Node{
>    public:
>          int a;
>          int b;
> };
> 
> extern "C" void demoNew(void) {
>          Node *n0 = new Node;
>          Node *n1 = (Node *)new char[sizeof(Node)];
>          printf("no=%p n1=%p\n", n0, n1);
>          delete n0;
>          delete[] n1;
> }
> 
> 
> int main(int argc, char ** argv) {
>          demoNew();
>          return 0;
> }

> --4747-- REDIR: 0x4d9b924 (libc.so:operator new[](unsigned long)) redirected to 0x4c1bb48 (operator new[](unsigned long))

> --4747-- REDIR: 0x4d9b8d8 (libc.so:operator new(unsigned long)) redirected to 0x4c1b7a4 (operator new(unsigned long))

Well, it is puzzling why 'operator new[]' and 'operator new' are in libc.so,
the run-time library for *plain*-C.  The C language does not have such functions.

> --4747-- REDIR: 0x4b44a60 (libc++.so:operator delete[](void*)) redirected to 0x4c1c3c4 (operator delete[](void*))

OK, that's the regular 'operator delete[]' for C++.
Where is 'operator delete', the non-array flavor?


> ==4747== Mismatched free() / delete / delete []
> ==4747==    at 0x4C1C44C: operator delete[](void*) (vg_replace_malloc.c:620)
> ==4747==    by 0x108797: demoNew (testNew.cpp:15)
> ==4747==    by 0x108797: main (testNew.cpp:20)
> ==4747==  Address 0x4eb9d70 is 0 bytes inside a block of size 8 alloc'd
> ==4747==    at 0x4C1B1F0: malloc (vg_replace_malloc.c:298)
> ==4747==    by 0x4B56CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)

That reference above to 'operator new(unsigned long)' should have been intercepted
directly by valgrind, instead of first calling malloc() [which was intercepted.]
Valgrind does not know about "stdlib_new_delete.cpp".  Which shared library is it in?

> ==4747==    by 0x10876F: demoNew (testNew.cpp:12)
> ==4747==    by 0x10876F: main (testNew.cpp:20)
> 
> localhost:/system/bin # nm -C  ../lib64/libc.so  | grep new

> 00000000000b2924 t operator new[](unsigned long)
> 00000000000b28d8 t operator new(unsigned long)

Again, I don't understand why libc.so has those functions.
Does it have also the corresponding 'delete' and 'delete[]'?

> 
> localhost:/system/bin # nm -C  ../lib64/libc++.so  | grep new
> 000000000005cd1c W operator new[](unsigned long)
> 000000000005cc8c W operator new(unsigned long)


My working hypothesis is that appearance in libc.so
of the code for some C++ operators, instead of appearing only in libc++.so,
has confused valgrind.  Also note that the C++ 'operator new'
is a 'W' (weak global) symbol, but the plain-C symbol 'operator new'
is a 't' (strong local) symbol.  A local symbol is not exported,
so it is visible only to calls from the same source file.
On the other hand, a weak symbol becomes hidden if there is
any [visible] strong definition.  This is very confusing.

[Valgrind-users] Introducing valgrind-preload project

[Yuri G. <tet...@gm...>]

Hi all,

I wanted to share a link to my project, Valgrind-preload
(https://github.com/yugr/valgrind-preload) to hopefully get some
comments, suggestions or bugreports.

Valgrind-preload is a simple LD_PRELOAD-able library which will cause
all spawned processes to be started under Valgrind. It's functionality
is similar to Valgrind's standard --trace-children=yes but fixes few
issues:
* avoids instrumenting setuid processes (Valgrind can't handle them so
you have to laboriously blacklist all of them via
--trace-children-skip which is unreliable and disables instrumentation
of grandchildren)
* can easily be enabled for the whole distro or chroot via
ld.so.preload (as there's no need to search for init and replace it
with custom wrapper)

The tool seems to be pretty stable now, e.g. I was able to instrument
complete Debian package builds and even found several new bugs (listed
on main page).

You can check the link above for additional details.

Thanks,
Yury Gribov

[Valgrind-users] 答复: 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

[Wuweijia <wuw...@hu...>]

Hi John:
	I wrote the simple example， error can re-producce.
	As below:
#include <stdio.h>
#include <stdlib.h>

class Node{
  public:
        int a;
        int b;
};

extern "C" void demoNew(void) {
        Node *n0 = new Node;
        Node *n1 = (Node *)new char[sizeof(Node)];
        printf("no=%p n1=%p\n", n0, n1);
        delete n0;
        delete[] n1;
}


int main(int argc, char ** argv) {
        demoNew();
        return 0;
} #include <stdio.h>
#include <stdlib.h>

class Node{
  public:
        int a;
        int b;
};

extern "C" void demoNew(void) {
        Node *n0 = new Node;
        Node *n1 = (Node *)new char[sizeof(Node)];
        printf("no=%p n1=%p\n", n0, n1);
        delete n0;
        delete[] n1; -----------------------------------------this is line 15
}
int main(int argc, char ** argv) {
        demoNew();
        return 0;
}

libc.so:operator new and (libc.so:operator new[] are separated.

--4747-- Reading syms from /system_P_EA1/lib64/valgrind/vgpreload_core-arm64-linux.so
linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
--4747-- REDIR: 0x4d0a130 (libc.so:memset) redirected to 0x4c1a2b4 (memset)
--4747-- REDIR: 0x4d51580 (libc.so:__memcpy_chk) redirected to 0x4c1aa1c (__memcpy_chk)
--4747-- REDIR: 0x4d06cec (libc.so:malloc) redirected to 0x4c1b168 (malloc)
--4747-- REDIR: 0x4d0a710 (libc.so:strlen) redirected to 0x4c1975c (strlen)
--4747-- REDIR: 0x4d51514 (libc.so:__strcpy_chk) redirected to 0x4c1a7ac (__strcpy_chk)
--4747-- REDIR: 0x4d0a89c (libc.so:strncmp) redirected to 0x4c19988 (strncmp)
--4747-- REDIR: 0x4d09c70 (libc.so:memcpy) redirected to 0x4c19dc8 (memcpy)
--4747-- REDIR: 0x4d9b924 (libc.so:operator new[](unsigned long)) redirected to 0x4c1bb48 (operator new[](unsigned long))
--4747-- REDIR: 0x4d09ab4 (libc.so:memchr) redirected to 0x4c19b94 (memchr)
--4747-- REDIR: 0x4d06f38 (libc.so:realloc) redirected to 0x4c1c734 (realloc)
--4747-- REDIR: 0x4d06bac (libc.so:free) redirected to 0x4c1bdac (free)
--4747-- REDIR: 0x4d09bc0 (libc.so:memcmp) redirected to 0x4c1a02c (bcmp)
--4747-- REDIR: 0x4d0a540 (libc.so:strcmp) redirected to 0x4c19b54 (strcmp)
--4747-- REDIR: 0x4d9b8d8 (libc.so:operator new(unsigned long)) redirected to 0x4c1b7a4 (operator new(unsigned long))
--4747-- REDIR: 0x4d8f620 (libc.so:strstr) redirected to 0x4c1abe8 (strstr)
no=0x4eb9d20 n1=0x4eb9d70
--4747-- REDIR: 0x4b44a60 (libc++.so:operator delete[](void*)) redirected to 0x4c1c3c4 (operator delete[](void*))
==4747== Mismatched free() / delete / delete []
==4747==    at 0x4C1C44C: operator delete[](void*) (vg_replace_malloc.c:620)
==4747==    by 0x108797: demoNew (testNew.cpp:15)
==4747==    by 0x108797: main (testNew.cpp:20)
==4747==  Address 0x4eb9d70 is 0 bytes inside a block of size 8 alloc'd
==4747==    at 0x4C1B1F0: malloc (vg_replace_malloc.c:298)
==4747==    by 0x4B56CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)
==4747==    by 0x10876F: demoNew (testNew.cpp:12)
==4747==    by 0x10876F: main (testNew.cpp:20)

localhost:/system/bin # nm -C  ../lib64/libc.so  | grep new
00000000000259c8 t prop_area::new_prop_bt(char const*, unsigned int, unsigned int*)
0000000000025b18 t prop_area::new_prop_info(char const*, unsigned int, char const*, unsigned int, unsigned int*)
00000000000b2924 t operator new[](unsigned long)
00000000000b28d8 t operator new(unsigned long)
00000000000d0468 t je_arena_new
00000000000de260 t je_extent_tree_ad_new
00000000000dd78c t je_extent_tree_szsnad_new
00000000000ea038 t je_rtree_new
0000000000035004 T newlocale
000000000007f16c t nonnewline

localhost:/system/bin # nm -C  ../lib64/libc++.so  | grep new
000000000005cd1c W operator new[](unsigned long)
000000000005cd20 W operator new[](unsigned long, std::nothrow_t const&)
000000000005ce34 W operator new[](unsigned long, std::align_val_t)
000000000005ce38 W operator new[](unsigned long, std::align_val_t, std::nothrow_t const&)
000000000005cc8c W operator new(unsigned long)
000000000005ccf0 W operator new(unsigned long, std::nothrow_t const&)
000000000005cd5c W operator new(unsigned long, std::align_val_t)
000000000005ce08 W operator new(unsigned long, std::align_val_t, std::nothrow_t const&)


-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2018年4月12日 4:23
收件人: val...@li...
主题: Re: [Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

On 04/10/2018 08:32 PM, Wuweijia wrote:
> Hi John：
> 	I follow your instruction that upgrade the valgrind  from 3.12 to 3.13.   It seem to be okay, Thank you. I did not find any change in the vg_preload.c vg_redir.c .  Can you tell me why the error  do not occur.
> 
> 	But there is some mistake, I  still need to find out why.
> 	
> 	I run the aarch64 Application, with valgrind 3.13..
> 	It show me this error:
> ==23233== Mismatched free() / delete / delete []
> ==23233==    at 0x582144C: operator delete[](void*) (vg_replace_malloc.c:620)
> ==23233==    by 0x531351B: android::List<android::sp<android::IVPBuffer> >::~List() (List.h:174)

> ==23233==  Address 0x4ae91c0 is 0 bytes inside a block of size 24 alloc'd
> ==23233==    at 0x582082C: operator new(unsigned long) (vg_replace_malloc.c:333)----------------show me  I call new() function  not new[]
> ==23233==    by 0x531349F: android::List<android::sp<android::IVPBuffer> >::prep() (List.h:294)

> And then I objdump the so , the machine code show me as below:
>   000000000000446c <android::List<android::sp<android::IVPBuffer> >::prep()>:
> _ZN7android4ListINS_2spINS_9IVPBufferEEEE4prepEv():
> system/core/libutils/include/utils/List.h:293
>      446c:	d10083ff 	sub	sp, sp, #0x20
>      4470:	a9017bfd 	stp	x29, x30, [sp,#16]
>      4474:	910043fd 	add	x29, sp, #0x10
>      4478:	b27d07e8 	orr	x8, xzr, #0x18
>      447c:	f90007e0 	str	x0, [sp,#8]
>      4480:	f94007e0 	ldr	x0, [sp,#8]
> system/core/libutils/include/utils/List.h:294
>      4484:	f90003e0 	str	x0, [sp]
>      4488:	aa0803e0 	mov	x0, x8
>      448c:	97fffb8b 	bl	32b8 <operator new[](unsigned long)@plt> -------------------It show me I used the new[] function not the new(),but valgrind show me I used the new()

Now we need to see the details of the redirections that valgrind performs:
intercepting calls to 'operator new' and 'operator new[]', and calling their replacements in vg_replace_malloc.c instead.

Please run
    valgrind -v ./my_app
and report the  REDIR  lines, such as:
    --9315-- REDIR: 0x4ec9b40 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2e87b (operator new[](unsigned long)) We want to see if both 'operator new' and 'operator new[]' are intercepted separately.

Also, please show the difference between the address of the 'operator new' subroutine and the address of the 'operator new[]' subroutine.  There may be low-level optimizations where 'operator new[]' tail merges into 'opeartor new' such that it is difficult to track the difference.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] vgdb : vgdb-pipe-shared-mem unexpected size

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

> Indeed, I found the version mismatch version.
> 
> callgrind_control script is directly calling "vgdb" thus retrieving the first and old executable found in my path and not the one that was in the same repository than valgrind exec and callgrind_control script.

https://bugs.kde.org/show_bug.cgi?id=393023
"callgrind_control risks using the wrong vgdb"

Re: [Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

On 04/10/2018 08:32 PM, Wuweijia wrote:
> Hi John：
> 	I follow your instruction that upgrade the valgrind  from 3.12 to 3.13.   It seem to be okay, Thank you. I did not find any change in the vg_preload.c vg_redir.c .  Can you tell me why the error  do not occur.
> 
> 	But there is some mistake, I  still need to find out why.
> 	
> 	I run the aarch64 Application, with valgrind 3.13..
> 	It show me this error:
> ==23233== Mismatched free() / delete / delete []
> ==23233==    at 0x582144C: operator delete[](void*) (vg_replace_malloc.c:620)
> ==23233==    by 0x531351B: android::List<android::sp<android::IVPBuffer> >::~List() (List.h:174)

> ==23233==  Address 0x4ae91c0 is 0 bytes inside a block of size 24 alloc'd
> ==23233==    at 0x582082C: operator new(unsigned long) (vg_replace_malloc.c:333)----------------show me  I call new() function  not new[]
> ==23233==    by 0x531349F: android::List<android::sp<android::IVPBuffer> >::prep() (List.h:294)

> And then I objdump the so , the machine code show me as below:
>   000000000000446c <android::List<android::sp<android::IVPBuffer> >::prep()>:
> _ZN7android4ListINS_2spINS_9IVPBufferEEEE4prepEv():
> system/core/libutils/include/utils/List.h:293
>      446c:	d10083ff 	sub	sp, sp, #0x20
>      4470:	a9017bfd 	stp	x29, x30, [sp,#16]
>      4474:	910043fd 	add	x29, sp, #0x10
>      4478:	b27d07e8 	orr	x8, xzr, #0x18
>      447c:	f90007e0 	str	x0, [sp,#8]
>      4480:	f94007e0 	ldr	x0, [sp,#8]
> system/core/libutils/include/utils/List.h:294
>      4484:	f90003e0 	str	x0, [sp]
>      4488:	aa0803e0 	mov	x0, x8
>      448c:	97fffb8b 	bl	32b8 <operator new[](unsigned long)@plt> -------------------It show me I used the new[] function not the new(),but valgrind show me I used the new()

Now we need to see the details of the redirections that valgrind performs:
intercepting calls to 'operator new' and 'operator new[]',
and calling their replacements in vg_replace_malloc.c instead.

Please run
    valgrind -v ./my_app
and report the  REDIR  lines, such as:
    --9315-- REDIR: 0x4ec9b40 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2e87b (operator new[](unsigned long))
We want to see if both 'operator new' and 'operator new[]' are intercepted separately.

Also, please show the difference between the address of the 'operator new' subroutine
and the address of the 'operator new[]' subroutine.  There may be low-level optimizations
where 'operator new[]' tail merges into 'opeartor new' such that it is difficult
to track the difference.

Re: [Valgrind-users] vgdb : vgdb-pipe-shared-mem unexpected size

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

> $ valgrind –version
> 
> valgrind-3.13.0
> 
> $ callgrind_control --version
> 
> callgrind_control-3.13.0

> valgrind, vgdb, and the executable were compiled with GCC 4.9.3
> 
> run on Linux kernel 2.6.32
> uname -a
> Linux 2.6.32.23-0.3-default #1 SMP 2010-10-07 14:57:45 +0200 x86_64 x86_64 x86_64 GNU/Linux
> 
> Here is the monitored executable:
> ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), for GNU/Linux 2.6.32, dynamically linked (uses shared libs), not stripped

>>         $ callgrind_control –i off
>> 
>>         error size shared memory file vgdb-pipe-shared-mem-vgdb-...
>> 
>>         expecting size 40 (64bits) or 32 (32bits) got 48.
>> 

There is a mismatch between callgrind_control and callgrind.
That Linux 2.6.32... was built on 2010-10-07 which is 7.5 years ago.
What are the dates of callgrind_control and callgrind?
    $ ls -l $(which callgrind callgrind_control)

The output from "git blame coregrind/pub_core_gdbserver.h" says:
=====
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 216) typedef
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 217)    struct {
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 218)       volatile int written_by_vgdb;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 219)       volatile int seen_by_valgrind;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 220)
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 221)       Addr64 invoke_gdbserver;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 222)
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 223)       Addr64 threads;
025b320e (Philippe Waroquiers 2015-02-09 21:30:58 +0000 224)       int vg_n_threads;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 225)       int sizeof_ThreadState;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 226)       int offset_status;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 227)       int offset_lwpid;
564e6857 (Philippe Waroquiers 2012-02-22 19:47:27 +0000 228)
564e6857 (Philippe Waroquiers 2012-02-22 19:47:27 +0000 229)       int vgdb_pid;
2ee9e904 (Julian Seward       2011-05-06 21:02:55 +0000 230)    } VgdbShared64;
=====
Notice that vg_n_threads was inserted in 2015, three or four years after all other members.
The individual sizes sum to (4+4 +8 +8+4+4+4+4 +4) = 44 bytes
but the alignment of 8 for Addr64 forces sizeof(VgdbShared64) to be 48 bytes.

sizeof(VgdbShared64) would be 40 bytes if vg_n_threads were omitted.
So it looks like callgrind_control may have been compiled from old source.
Check the source code, then recompile callgrind_control.

Re: [Valgrind-users] vgdb : vgdb-pipe-shared-mem unexpected size

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

> I am using callgrind on Linux. I get an error when using callgrind_control and I cannot find out where it's coming from.
> 
> $ valgrind –version
> 
> valgrind-3.13.0
> 
> $ callgrind_control --version
> 
> callgrind_control-3.13.0

Thank you for stating the versions!

> 
> Callgrind is working fine but when using callgrind_control, I have the following error:
> 
> $ callgrind_control –i off
> 
> error size shared memory file vgdb-pipe-shared-mem-vgdb-...
> 
> expecting size 40 (64bits) or 32 (32bits) got 48.
> 
> OK.
> 
> 
> 
> Indeed the  vgdb-pipe-shared-mem file size is 48B. And indeed reading the code, it's expecting 40B. Would you have any idea of what'g going wrong here?

There is some disagreement about sizeof() some type or struct.
Which compiler and version was used to build callgrind and callgrind_control?

What is the CPU hardware architecture of the host (where callgrind_control
is running: "$ uname -m -p -i") and the target (the execution being
measured: "$ file ./my_app")?