valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

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

On 10/07/2019 16:17, Julian Seward wrote:
> 
>  > Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind
>  > --version)
> 
> In that case you're not running the version you compiled.
> 
> Try running 3.15 and give it the flag --keep-debuginfo=yes.  Does that 
> help?

If it was an so that had been unloaded then I don't think it would
even show the name would it? So I'm not sure --keep-debuginfo=yes
will help...

Tom

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

Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

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

 > Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind
 > --version)

In that case you're not running the version you compiled.

Try running 3.15 and give it the flag --keep-debuginfo=yes.  Does that help?

J

Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

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

On 10/07/2019 15:46, robert somerville wrote:

> Although I can debug this fine with Totalview, and even use Totalview 
> memory debugger to find detailed location info on  memory leaks, 
> Valgrind (memcheck) is only giving me the vaguest info such as (below) :
> 
> Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind 
> --version)
> 
> It should be possible to get more detailed info out of 
> Valgrind(memcheck), such as routine and line numbers ??

Well sure, if the files are compiled with debug information.

Apparently they aren't, so you don't get anything more.

Tom

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

[Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

[robert s. <rbr...@gm...>]

Although I can debug this fine with Totalview, and even use Totalview
memory debugger to find detailed location info on  memory leaks, Valgrind
(memcheck) is only giving me the vaguest info such as (below) :

Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind
--version)

It should be possible to get more detailed info out of Valgrind(memcheck),
such as routine and line numbers ??



  ==49825==
==49825== 1,066,081 (23,800 direct, 1,042,281 indirect) bytes in 35 blocks
are definitely lost in loss record 31,654 of 31,655
==49825==    at 0x4A07155: operator new(unsigned long)
(vg_replace_malloc.c:334)
==49825==    by 0x1D821C2A: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libseisutil.so)
==49825==    by 0x660CE78: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x6652CD9: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x66A872C: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x603F3DF: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x657EC7F: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x6580C67: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x6994D2D: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x23587692: QMetaObject::activate(QObject*, int, int,
void**) (in
/net/GeoSoftware/local/GS_Toolchest/Qt-5.11.3-linux64-gcc8-minimal/lib/libQt5Core.so.5.11.3)
==49825==    by 0x6929E4F: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)
==49825==    by 0x5D0C103: ??? (in
/home/rsomervi/GS_code/GS_code_Trunk/hrs/build/lib/linux64/gcc8/hrs/Debug/libgseismic_qt4.so)

TIA:
Robert Somerville

[Valgrind-users] valgrind failed to run on cavium octeon3 mips64

[<443...@qq...>]

Hi,


I tried to run valgrind on my  cavium octeon3 mips64 board, but failed to let it work. please give me help! 

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

root@Openwrt:/tmp# valgrind -v /bin/true
==9303== Memcheck, a memory error detector
==9303== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9303== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info
==9303== Command: /bin/true
==9303==
--9303-- Valgrind options:
--9303--    -v
--9303-- Contents of /proc/version:
--9303--   Linux version 3.10.87 (root@PowerEdge-T130) (gcc version 4.7.0 (Cavium Inc. Version: SDK_BUILD build 49) ) #931 SMP Sat Jul 6 13:36:22 CST 2019
--9303--
--9303-- Arch and hwcaps: MIPS64, BigEndian, Cavium-baseline
--9303-- Page sizes: currently 4096, max supported 65536
--9303-- Valgrind library directory: /usr/lib/valgrind
--9303-- Reading syms from /lib/ld-2.16.so
--9303-- Reading syms from /bin/busybox
--9303-- warning: DiCfSI 0x0 .. 0x17 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x0 .. 0x3 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x4 .. 0x7 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x18 .. 0x2b outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x2c .. 0x73 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x0 .. 0x3 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x4 .. 0x7 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x18 .. 0x77 outside mapped rx segments (NONE)
--9303-- Reading syms from /usr/lib/valgrind/memcheck-mips64-linux
--9303--    object doesn't have a dynamic symbol table
--9303-- Scheduler: using generic scheduler lock implementation.
--9303-- Reading suppressions file: /usr/lib/valgrind/default.supp
==9303== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9303-by-superroot-on-???
==9303== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-9303-by-superroot-on-???
==9303== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-9303-by-superroot-on-???
==9303==
==9303== TO CONTROL THIS PROCESS USING vgdb (which you probably
==9303== don't want to do, unless you know exactly what you're doing,
==9303== or are doing some strange experiment):
==9303==   /usr/lib/valgrind/../../bin/vgdb --pid=9303 ...command...
==9303==
==9303== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==9303==   /path/to/gdb /bin/true
==9303== and then give GDB the following command
==9303==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=9303
==9303== --pid is optional if only one valgrind process is running
==9303==
--9303-- REDIR: 0x401ce00 (ld.so.1:strlen) redirected to 0x58115be4 (vgPlain_mips64_linux_REDIR_FOR_strlen)
--9303-- REDIR: 0x401ca80 (ld.so.1:index) redirected to 0x58115bc0 (vgPlain_mips64_linux_REDIR_FOR_index)
--9303-- Reading syms from /usr/lib/valgrind/vgpreload_core-mips64-linux.so
--9303-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-mips64-linux.so
--9303-- REDIR: 0x401d930 (ld.so.1:mempcpy) redirected to 0x40631c0 (mempcpy)
--9303-- REDIR: 0x401d2e0 (ld.so.1:bcmp) redirected to 0x405bef0 (bcmp)
--9303-- REDIR: 0x401da40 (ld.so.1:memcpy) redirected to 0x4056b18 (memcpy)
--9303-- Reading syms from /lib/libcrypt-2.16.so
--9303-- Reading syms from /lib/libm-2.16.so
--9303-- Reading syms from /lib/libpam.so.0.83.1
--9303-- Reading syms from /lib/libpam_misc.so.0.82.0
--9303-- Reading syms from /lib/libc-2.16.so
--9303-- Reading syms from /lib/libdl-2.16.so
--9303-- REDIR: 0x42ab310 (libc.so.6:rindex) redirected to 0x404b700 (rindex)
==9303== Invalid read of size 8
==9303==    at 0x4251EE4: __ctype_init (ctype-info.c:32)
==9303==    by 0x4242C8C: _init (init-first.c:97)
==9303==    by 0x40129D8: call_init (dl-init.c:69)
==9303==    by 0x40129D8: call_init (dl-init.c:34)
==9303==    by 0x4012BC8: _dl_init (dl-init.c:133)
==9303==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==9303==  Address 0xffffffffffff9000 is not stack'd, malloc'd or (recently) free'd
==9303==
==9303==
==9303== Process terminating with default action of signal 10 (SIGBUS)
==9303==    at 0x4251EE4: __ctype_init (ctype-info.c:32)
==9303==    by 0x4242C8C: _init (init-first.c:97)
==9303==    by 0x40129D8: call_init (dl-init.c:69)
==9303==    by 0x40129D8: call_init (dl-init.c:34)
==9303==    by 0x4012BC8: _dl_init (dl-init.c:133)
==9303==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==9303==
==9303== Process terminating with default action of signal 10 (SIGBUS)
==9303==    at 0x4019508: __dl_runtime_resolve (dl-trampoline.c:178)
==9303==    by 0x40192D8: _dl_runtime_resolve (in /lib/ld-2.16.so)
==9303==
==9303== HEAP SUMMARY:
==9303==     in use at exit: 0 bytes in 0 blocks
==9303==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9303==
==9303== All heap blocks were freed -- no leaks are possible
==9303==
==9303== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
==9303==
==9303== 1 errors in context 1 of 1:
==9303== Invalid read of size 8
==9303==    at 0x4251EE4: __ctype_init (ctype-info.c:32)
==9303==    by 0x4242C8C: _init (init-first.c:97)
==9303==    by 0x40129D8: call_init (dl-init.c:69)
==9303==    by 0x40129D8: call_init (dl-init.c:34)
==9303==    by 0x4012BC8: _dl_init (dl-init.c:133)
==9303==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==9303==  Address 0xffffffffffff9000 is not stack'd, malloc'd or (recently) free'd
==9303==
--9303--
--9303-- used_suppression:      1 ld(Addr4) /usr/lib/valgrind/default.supp:14
==9303==
==9303== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
Bus error


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


Thanks in advance.


Bryan

[Valgrind-users] valgrind failed to run on cavium octeon3 mips64

[<443...@qq...>]

Hi,


I tried to run valgrind on my  cavium octeon3 mips64 board, but failed to let it work. please give me help! 

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

root@Openwrt:/tmp# valgrind -v /bin/true
==9303== Memcheck, a memory error detector
==9303== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9303== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info
==9303== Command: /bin/true
==9303==
--9303-- Valgrind options:
--9303--    -v
--9303-- Contents of /proc/version:
--9303--   Linux version 3.10.87 (root@PowerEdge-T130) (gcc version 4.7.0 (Cavium Inc. Version: SDK_BUILD build 49) ) #931 SMP Sat Jul 6 13:36:22 CST 2019
--9303--
--9303-- Arch and hwcaps: MIPS64, BigEndian, Cavium-baseline
--9303-- Page sizes: currently 4096, max supported 65536
--9303-- Valgrind library directory: /usr/lib/valgrind
--9303-- Reading syms from /lib/ld-2.16.so
--9303-- Reading syms from /bin/busybox
--9303-- warning: DiCfSI 0x0 .. 0x17 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x0 .. 0x3 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x4 .. 0x7 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x18 .. 0x2b outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x2c .. 0x73 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x0 .. 0x3 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x4 .. 0x7 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--9303-- warning: DiCfSI 0x18 .. 0x77 outside mapped rx segments (NONE)
--9303-- Reading syms from /usr/lib/valgrind/memcheck-mips64-linux
--9303--    object doesn't have a dynamic symbol table
--9303-- Scheduler: using generic scheduler lock implementation.
--9303-- Reading suppressions file: /usr/lib/valgrind/default.supp
==9303== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9303-by-superroot-on-???
==9303== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-9303-by-superroot-on-???
==9303== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-9303-by-superroot-on-???
==9303==
==9303== TO CONTROL THIS PROCESS USING vgdb (which you probably
==9303== don't want to do, unless you know exactly what you're doing,
==9303== or are doing some strange experiment):
==9303==   /usr/lib/valgrind/../../bin/vgdb --pid=9303 ...command...
==9303==
==9303== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==9303==   /path/to/gdb /bin/true
==9303== and then give GDB the following command
==9303==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=9303
==9303== --pid is optional if only one valgrind process is running
==9303==
--9303-- REDIR: 0x401ce00 (ld.so.1:strlen) redirected to 0x58115be4 (vgPlain_mips64_linux_REDIR_FOR_strlen)
--9303-- REDIR: 0x401ca80 (ld.so.1:index) redirected to 0x58115bc0 (vgPlain_mips64_linux_REDIR_FOR_index)
--9303-- Reading syms from /usr/lib/valgrind/vgpreload_core-mips64-linux.so
--9303-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-mips64-linux.so
--9303-- REDIR: 0x401d930 (ld.so.1:mempcpy) redirected to 0x40631c0 (mempcpy)
--9303-- REDIR: 0x401d2e0 (ld.so.1:bcmp) redirected to 0x405bef0 (bcmp)
--9303-- REDIR: 0x401da40 (ld.so.1:memcpy) redirected to 0x4056b18 (memcpy)
--9303-- Reading syms from /lib/libcrypt-2.16.so
--9303-- Reading syms from /lib/libm-2.16.so
--9303-- Reading syms from /lib/libpam.so.0.83.1
--9303-- Reading syms from /lib/libpam_misc.so.0.82.0
--9303-- Reading syms from /lib/libc-2.16.so
--9303-- Reading syms from /lib/libdl-2.16.so
--9303-- REDIR: 0x42ab310 (libc.so.6:rindex) redirected to 0x404b700 (rindex)
==9303== Invalid read of size 8
==9303==    at 0x4251EE4: __ctype_init (ctype-info.c:32)
==9303==    by 0x4242C8C: _init (init-first.c:97)
==9303==    by 0x40129D8: call_init (dl-init.c:69)
==9303==    by 0x40129D8: call_init (dl-init.c:34)
==9303==    by 0x4012BC8: _dl_init (dl-init.c:133)
==9303==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==9303==  Address 0xffffffffffff9000 is not stack'd, malloc'd or (recently) free'd
==9303==
==9303==
==9303== Process terminating with default action of signal 10 (SIGBUS)
==9303==    at 0x4251EE4: __ctype_init (ctype-info.c:32)
==9303==    by 0x4242C8C: _init (init-first.c:97)
==9303==    by 0x40129D8: call_init (dl-init.c:69)
==9303==    by 0x40129D8: call_init (dl-init.c:34)
==9303==    by 0x4012BC8: _dl_init (dl-init.c:133)
==9303==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==9303==
==9303== Process terminating with default action of signal 10 (SIGBUS)
==9303==    at 0x4019508: __dl_runtime_resolve (dl-trampoline.c:178)
==9303==    by 0x40192D8: _dl_runtime_resolve (in /lib/ld-2.16.so)
==9303==
==9303== HEAP SUMMARY:
==9303==     in use at exit: 0 bytes in 0 blocks
==9303==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9303==
==9303== All heap blocks were freed -- no leaks are possible
==9303==
==9303== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
==9303==
==9303== 1 errors in context 1 of 1:
==9303== Invalid read of size 8
==9303==    at 0x4251EE4: __ctype_init (ctype-info.c:32)
==9303==    by 0x4242C8C: _init (init-first.c:97)
==9303==    by 0x40129D8: call_init (dl-init.c:69)
==9303==    by 0x40129D8: call_init (dl-init.c:34)
==9303==    by 0x4012BC8: _dl_init (dl-init.c:133)
==9303==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==9303==  Address 0xffffffffffff9000 is not stack'd, malloc'd or (recently) free'd
==9303==
--9303--
--9303-- used_suppression:      1 ld(Addr4) /usr/lib/valgrind/default.supp:14
==9303==
==9303== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
Bus error


------------------------------------------------------------------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

another log to run pthread app: 



root@openwrt:~# valgrind -v /bin/linkmgr
==25092== Memcheck, a memory error detector
==25092== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25092== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info
==25092== Command: /bin/linkmgr
==25092==
--25092-- Valgrind options:
--25092--    -v
--25092-- Contents of /proc/version:
--25092--   Linux version 3.10.87 (root@PowerEdge-T130) (gcc version 4.7.0 (Cavium Inc. Version: SDK_BUILD build 49) ) #931 SMP Sat Jul 6 13:36:22 CST 2019
--25092--
--25092-- Arch and hwcaps: MIPS64, BigEndian, Cavium-baseline
--25092-- Page sizes: currently 4096, max supported 65536
--25092-- Valgrind library directory: /usr/lib/valgrind
--25092-- Reading syms from /lib/ld-2.16.so
--25092-- Reading syms from /bin/linkmgr
--25092-- Reading syms from /usr/lib/valgrind/memcheck-mips64-linux
--25092--    object doesn't have a dynamic symbol table
--25092-- Scheduler: using generic scheduler lock implementation.
--25092-- Reading suppressions file: /usr/lib/valgrind/default.supp
==25092== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-25092-by-superroot-on-???
==25092== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-25092-by-superroot-on-???
==25092== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-25092-by-superroot-on-???
==25092==
==25092== TO CONTROL THIS PROCESS USING vgdb (which you probably
==25092== don't want to do, unless you know exactly what you're doing,
==25092== or are doing some strange experiment):
==25092==   /usr/lib/valgrind/../../bin/vgdb --pid=25092 ...command...
==25092==
==25092== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==25092==   /path/to/gdb /bin/linkmgr
==25092== and then give GDB the following command
==25092==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=25092
==25092== --pid is optional if only one valgrind process is running
==25092==
--25092-- REDIR: 0x401ce00 (ld.so.1:strlen) redirected to 0x58115be4 (vgPlain_mips64_linux_REDIR_FOR_strlen)
--25092-- REDIR: 0x401ca80 (ld.so.1:index) redirected to 0x58115bc0 (vgPlain_mips64_linux_REDIR_FOR_index)
--25092-- Reading syms from /usr/lib/valgrind/vgpreload_core-mips64-linux.so
--25092-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-mips64-linux.so
--25092-- REDIR: 0x401d930 (ld.so.1:mempcpy) redirected to 0x40631c0 (mempcpy)
--25092-- REDIR: 0x401d2e0 (ld.so.1:bcmp) redirected to 0x405bef0 (bcmp)
--25092-- REDIR: 0x401da40 (ld.so.1:memcpy) redirected to 0x4056b18 (memcpy)
--25092-- Reading syms from /lib/libpthread-2.16.so
--25092-- Reading syms from /lib/librt-2.16.so
--25092-- Reading syms from /lib/libstdc++.so.6.0.17
--25092-- Reading syms from /lib/libdl-2.16.so
--25092-- Reading syms from /usr/lib/libz.so.1.2.8
--25092-- Reading syms from /lib/libm-2.16.so
--25092-- Reading syms from /lib/libuci.so
--25092-- Reading syms from /lib/libubox.so
--25092-- Reading syms from /lib/libubus.so
--25092-- Reading syms from /lib/libblobmsg_json.so
--25092-- Reading syms from /usr/lib/libjson-c.so.2.0.1
--25092-- Reading syms from /usr/lib/libssl.so.1.0.0
--25092-- Reading syms from /usr/lib/libcrypto.so.1.0.0
--25092-- Reading syms from /lib/libgcc_s.so.1
--25092-- Reading syms from /lib/libc-2.16.so
==25092== Invalid write of size 1
==25092==    at 0x4085044: __pthread_initialize_minimal (nptl-init.c:309)
==25092==    by 0x4083A58: ??? (in /lib/libpthread-2.16.so)
==25092==  Address 0xffffffffffff8d12 is not stack'd, malloc'd or (recently) free'd
==25092==
==25092==
==25092== Process terminating with default action of signal 10 (SIGBUS)
==25092==    at 0x4085044: __pthread_initialize_minimal (nptl-init.c:309)
==25092==    by 0x4083A58: ??? (in /lib/libpthread-2.16.so)
==25092==
==25092== Process terminating with default action of signal 10 (SIGBUS)
==25092==    at 0x4019508: __dl_runtime_resolve (dl-trampoline.c:178)
==25092==    by 0x40192D8: _dl_runtime_resolve (in /lib/ld-2.16.so)
==25092==
==25092== HEAP SUMMARY:
==25092==     in use at exit: 0 bytes in 0 blocks
==25092==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==25092==
==25092== All heap blocks were freed -- no leaks are possible
==25092==
==25092== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
==25092==
==25092== 1 errors in context 1 of 1:
==25092== Invalid write of size 1
==25092==    at 0x4085044: __pthread_initialize_minimal (nptl-init.c:309)
==25092==    by 0x4083A58: ??? (in /lib/libpthread-2.16.so)
==25092==  Address 0xffffffffffff8d12 is not stack'd, malloc'd or (recently) free'd
==25092==
--25092--
--25092-- used_suppression:      1 ld(Addr4) /usr/lib/valgrind/default.supp:14
==25092==
==25092== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
Bus error

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


Thanks in advance.


Bryan

Re: [Valgrind-users] --track-origins option is not working

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

On Tue, 2019-07-02 at 15:58 +0530, subhasish Karmakar wrote:
> Hi Julian,
> "/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so" file is still
> stripped
> even after rebuilding.
> Could you please suggest some way to resolve this issue.

A normal build doesn't remove debug information. How did you build
exactly? If you follow the build instructions in the README you should
get a normal, not stripped vgpreload library.

Cheers,

Mark

Re: [Valgrind-users] --track-origins option is not working

[subhasish K. <sub...@gm...>]

Hi Julian,
"/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so" file is still stripped
even after rebuilding.
Could you please suggest some way to resolve this issue.

Thanks,
Subhasish

On Wed, Jun 26, 2019 at 11:57 AM subhasish Karmakar <
sub...@gm...> wrote:

> Hi Julian,
>
> Below file is still stripped even after rebuilding,
>  /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
>
> I am using attched bitbake receipe to build valgrind.
> Can I modify the recipe file so that debug infromation is always included
> in vgpreload_memcheck-arm-linux.so ?
>
> Thanks,
> Subhasish
>
> On Tue, Jun 25, 2019 at 12:40 AM Julian Seward <js...@ac...> wrote:
>
>>
>> I guess that the problem is that the build of valgrind somehow removed
>> the debug (unwind) information on
>> /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
>> and that's why there is no backtrace.  Can you rebuild valgrind so that
>> the debug information on that file is preserved?
>>
>> J
>>
>

Re: [Valgrind-users] --track-origins option is not working

[subhasish K. <sub...@gm...>]

Hi Julian,

Below file is still stripped even after rebuilding,
 /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so

I am using attched bitbake receipe to build valgrind.
Can I modify the recipe file so that debug infromation is always included
in vgpreload_memcheck-arm-linux.so ?

Thanks,
Subhasish

On Tue, Jun 25, 2019 at 12:40 AM Julian Seward <js...@ac...> wrote:

>
> I guess that the problem is that the build of valgrind somehow removed
> the debug (unwind) information on
> /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
> and that's why there is no backtrace.  Can you rebuild valgrind so that
> the debug information on that file is preserved?
>
> J
>

Re: [Valgrind-users] --track-origins option is not working

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

On 6/25/19 09:57 UTC, subhasish Karmakar wrote:
> Hi,> Can someone help me to resolve this issue.

Did you read Julian Seward's response of Mon, 24 Jun 2019 21:10:48 +0200 ?

What does the shell command
     file /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
report?  If the output contains the word "stripped", then
that likely is the problem.  Rebuild so that it is not stripped.

Re: [Valgrind-users] --track-origins option is not working

[subhasish K. <sub...@gm...>]

Hi,
Can someone help me to resolve this issue.

Thanks,
Subhasish

On Mon, Jun 24, 2019 at 10:03 PM subhasish Karmakar <
sub...@gm...> wrote:

> Hi,
>
> I am using embedded linux to run my application.
>
> I do not get any memory leak information with valgrind, when I set “
> *--track-origins=yes*”.
>
> Without *--track-origins* option, I can see memory leak errors, but file
> name and line number is not displayed.
>
> I have attached valgrind logs for reference.
>
>
>
> My application is compiled with “*-g -o0*” compiler flags and my
> open-embedded core does not support GDB.
> Kindly let me know, how to get more debug information for memory leaks in
> my application.
>
> Thanks for your support,
> Subhasish
>

Re: [Valgrind-users] Error report: Valgrind hangs after SIGKILL

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

> I have detected the following issue while running Valgrind on a
> multi-threaded application. Valbrind hangs if the application raises the
> signal SIGKILLl to suicide.

Is the hang reproducible in a small test case, such as only two threads
that do "nothing" except possibly wait for synchronization and/or signals?

Re: [Valgrind-users] --track-origins option is not working

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

I guess that the problem is that the build of valgrind somehow removed
the debug (unwind) information on
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
and that's why there is no backtrace.  Can you rebuild valgrind so that
the debug information on that file is preserved?

J

[Valgrind-users] --track-origins option is not working

[subhasish K. <sub...@gm...>]

Hi,

I am using embedded linux to run my application.

I do not get any memory leak information with valgrind, when I set “
*--track-origins=yes*”.

Without *--track-origins* option, I can see memory leak errors, but file
name and line number is not displayed.

I have attached valgrind logs for reference.



My application is compiled with “*-g -o0*” compiler flags and my
open-embedded core does not support GDB.
Kindly let me know, how to get more debug information for memory leaks in
my application.

Thanks for your support,
Subhasish

[Valgrind-users] Error report: Valgrind hangs after SIGKILL

[Andrey S. <and...@vi...>]

Hello,

I have detected the following issue while running Valgrind on a 
multi-threaded application. Valbrind hangs if the application raises the 
signal SIGKILLl to suicide.

# strace -ff valgind <the app> -c 'sigraise 9'

shows SIGKILL neither sent nor received by any thread; it just shows the
main thread exits and the second thread getting stuck waiting on a futex.

-- 
With the best regards,
Andrey Shinkevich

[Valgrind-users] Valgrind reporting memory errors inside allocated regions?

[Tae L. K. <ur...@pr...>]

Hi,

I tried running my program under Valgrind to look for any pesky memory corruption bugs, but in addition to taking an inordinately long time to start up (e.g. creating the font atlas takes 3 minutes), I get a lot of errors about invalid reads and writes such as those listed in this attachment. What really baffles me is that they show that the reads happened in a region of allocated memory.

My initial guess is that it has something to do with my program handling memory very weirdly: some of the code switches the stack pointer in order to implement coroutines. In fact, Valgrind does warn of this.

My code is here in case anyone actually wants to try it:
https://gitlab.com/nagakawa/tdr

– T

[Valgrind-users] How to avoid unexpected memory allocation

[邓道宽 <dd...@gm...>]

Hi all
I just write a small MemoryHook library with c++ and use as preload.But
every time I start running, there is a big memory allocation,the size is
72704.I try to find all related library in ldd  list, but no size is 72704.
The usage is like this:
    LD_PRELOAD=./libPreload.so ./XXX

My initialize code:
*    static void TraceInitialize()*


























*    {#ifdef _DEBUG        fprintf( stderr, "call TraceInitialize\n" );
 #endif        pthread_mutex_lock( &s_mutexInit );        if ( s_status ==
TS_INITIALIZED ) { pthread_mutex_unlock( &s_mutexInit ); return; }
s_status = TS_INITIALIZING;        MemoryManager::initialize();
  s_pRealMalloc       = (FUNC_MALLOC)dlsym(RTLD_NEXT, "malloc");
s_pRealCalloc       = (FUNC_CALLOC)dlsym(RTLD_NEXT, "calloc");
s_pRealRealloc      = (FUNC_REALLOC)dlsym(RTLD_NEXT, "realloc");
s_pRealMemalign     = (FUNC_MEMALIGN)dlsym(RTLD_NEXT, "memalign");
s_pRealValloc       = (FUNC_VALLOC)dlsym(RTLD_NEXT, "valloc");
s_pRealFree         = (FUNC_FREE)dlsym(RTLD_NEXT, "free");        assert(
!( NULL == s_pRealMalloc || NULL == s_pRealCalloc || NULL == s_pRealRealloc
||                     NULL == s_pRealMemalign || NULL == s_pRealValloc ||
NULL == s_pRealFree ) );               s_status = TS_INITIALIZED;       //
printMap();               pthread_mutex_unlock( &s_mutexInit );    }*

and trace malloc call:
*     static int s_no_hook = 0;*









*     void* TraceMalloc( size_t size )     {            if ( s_status ==
TS_INITIALIZING ) return mockMemory::_mockMalloc( size );          if (
s_status != TS_INITIALIZED )  TraceInitialize();          void* p =
_impMalloc( size, __sync_fetch_and_add( &s_no_hook, 1 ) );
__sync_fetch_and_sub( &s_no_hook, 1 );          return p;      }*

And there is an additional problem that can't count the memory release of
static global variables.I can't find a suitable time to do this,even with
__attribute__ ((destructor(101))).

How can I fix these two bugs?

Complete code link:
          https://github.com/ddkv587/MemoryHook

Re: [Valgrind-users] How to find memory leaks from an running application

[David F. <fa...@kd...>]

On jeudi 20 juin 2019 12:07:19 CEST Howard Chu wrote:
> David Chapman wrote:
> > On 6/19/2019 10:34 PM, subhasish Karmakar wrote:
> >> Hi,
> >> 
> >> I have an application running on embedded linux.
> >> After running for hours my application causes out of memory issue.
> >> How can I get memory leak report periodically when the application is
> >> running? It's a process with "while(1)" loop.
> 
> If your only problem is memory leaks and no other concerns (such as out of
> bounds accesses, corruptions, etc.) then you should give
> https://github.com/hyc/mleak/ a try. It is faster than all other memory
> leak detectors out there, fast enough to run in production. And you can
> send it a periodic signal to get a snapshot of currently allocated memory.

Or, for another LD_PRELOAD-based tool with a really nice user interface on 
top, https://github.com/KDAB/heaptrack

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] How to find memory leaks from an running application

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

On Thu, 2019-06-20 at 11:04 +0530, subhasish Karmakar wrote:
> Hi,
> 
> I have an application running on embedded linux.
> After running for hours my application causes out of memory issue.
> How can I get memory leak report periodically when the application is running?
> It's a process with "while(1)" loop.

You can search leaks with valgrind while your program is running.

Different techniques can be used for that:
  * Inside your code, you add calls to client requests
    such as VALGRIND_DO_LEAK_CHECK
  * From the shell, you can use 'vgdb' to launch
    a leak search using the monitor request 'leak check'
  * Using gdb+vgdb, you can also launch such a leak check.
    Compared to the previous techniques, the advantage is
    that you can just put breakpoints where you want, and
    launch leak searches when a breakpoints is reached.
    You can also explore the 'logical leaks' (increase of
    memory due to still reachable memory) using the monitor
    request 'who_points_at'.

Note that these leak searches can show a 'delta leak' report,
i.e. pinpoint at the new allocations since the previous leak
search.

See user manual for more details, e.g.
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
and 
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

Philippe

     

Re: [Valgrind-users] How to find memory leaks from an running application

[Howard C. <hy...@sy...>]

David Chapman wrote:
> On 6/19/2019 10:34 PM, subhasish Karmakar wrote:
>> Hi,
>>
>> I have an application running on embedded linux.
>> After running for hours my application causes out of memory issue.
>> How can I get memory leak report periodically when the application is running?
>> It's a process with "while(1)" loop.

If your only problem is memory leaks and no other concerns (such as out of bounds
accesses, corruptions, etc.) then you should give https://github.com/hyc/mleak/
a try. It is faster than all other memory leak detectors out there, fast enough
to run in production. And you can send it a periodic signal to get a snapshot
of currently allocated memory.

>>
>> Regards,
>> Subhasish
>>
> 
> Valgrind reports leaks when the program exits.  Because leaks are more than just memory that your program no longer references, there isn't a good way to report
> leaks before your program exits.
> 
> Your best bet is to build a version of your program that exits sooner, then run your embedded system until the program exits (vs. runs out of memory).  Unless
> your code leaks memory in very unusual circumstances, running it under valgrind for a few minutes should give you a lot of clues.  Figure out how many times the
> "while (1)" infinite loop iterates before the crash, divide that number by 100 or 1000, then replace the infinite loop with a "for (i = 0; i < count; ++i)" loop.
> 
> Remember, your program will run slower under valgrind, so if your embedded system has strict real-time constraints it might not work properly.
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: [Valgrind-users] How to find memory leaks from an running application

[David C. <dcc...@ac...>]

On 6/19/2019 10:34 PM, subhasish Karmakar wrote:
> Hi,
>
> I have an application running on embedded linux.
> After running for hours my application causes out of memory issue.
> How can I get memory leak report periodically when the application is 
> running?
> It's a process with "while(1)" loop.
>
> Regards,
> Subhasish
>

Valgrind reports leaks when the program exits.  Because leaks are more 
than just memory that your program no longer references, there isn't a 
good way to report leaks before your program exits.

Your best bet is to build a version of your program that exits sooner, 
then run your embedded system until the program exits (vs. runs out of 
memory).  Unless your code leaks memory in very unusual circumstances, 
running it under valgrind for a few minutes should give you a lot of 
clues.  Figure out how many times the "while (1)" infinite loop iterates 
before the crash, divide that number by 100 or 1000, then replace the 
infinite loop with a "for (i = 0; i < count; ++i)" loop.

Remember, your program will run slower under valgrind, so if your 
embedded system has strict real-time constraints it might not work properly.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com
     2018-2019 Chair, IEEE Consultants' Network of Silicon Valley

[Valgrind-users] How to find memory leaks from an running application

[subhasish K. <sub...@gm...>]

Hi,

I have an application running on embedded linux.
After running for hours my application causes out of memory issue.
How can I get memory leak report periodically when the application is
running?
It's a process with "while(1)" loop.

Regards,
Subhasish

Re: [Valgrind-users] Git access not possible

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

> My computer is located in Germany, and I cannot clone the source with git (git://sourceware.org/git/valgrind.git).

If you post a copy+paste transcript of a terminal session
which shows the _exact_ command and error message, then
it is likely that you may get better suggestions.

Re: [Valgrind-users] Git access not possible

[Paulo M. <pm...@li...>]

Try https:

git clone https://sourceware.org/git/valgrind.git

On 12/06/2019 14:14, Rasmus wrote:
> Hi,
> My computer is located in Germany, and I cannot clone the source with
> git (git://sourceware.org/git/valgrind.git).
> 
> Are there any known connection problems or mirrors I could use?
> 
> Regards,
> Rasmus
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

-- 
Paulo Matos

[Valgrind-users] Git access not possible

[Rasmus <jrd...@we...>]

Hi,
My computer is located in Germany, and I cannot clone the source with git (git://sourceware.org/git/valgrind.git).

Are there any known connection problems or mirrors I could use?

Regards,
Rasmus
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.