|
From: rajesh s. <inf...@gm...> - 2018-11-22 12:29:53
|
Hi All,
I configure and compiled valgrind with below command and compile valigrind
for mips architecture with CAVIUM tool chain.
thangarasu@Thangarasu-DT:~/RAJESH/Valgrind/valgrind-3.14.0$ ./configure
--host=mips64-linux-gnu
CC=/opt/CAVIUMsdk312/OCTEON-SDK/tools/bin/mips64-octeon-linux-gnu-gcc
CXX=/opt/CAVIUMsdk312/OCTEON-SDK/tools/bin/mips64-octeon-linux-gnu-g++
--prefix=/home/thangarasu/RAJESH/Valgrind/valgrind_bins
--exec-prefix=/home/thangarasu/RAJESH/Valgrind/valgrind_bins
--build=mips64-pc-linux --enable-tls CFLAGS="-march=octeon2 -mabi=64"
make
make install
I compiled a simple c program test.c with same toolchain as below:
test.c:
#include<stdio.h>
#include<stdlib.h>
int main()
{
int *ptr = (int*)malloc(10);
return 0;
}
thangarasu@Thangarasu-DT:~/RAJESH/Valgrind$
/opt/CAVIUMsdk312/OCTEON-SDK/tools/bin/mips64-octeon-linux-gnu-gcc -o
test1 test.c
I copied both valgrind binary and test1 binary on node.
Now ran the valgrind with program test1 but its show no memory leak and
logs are as below:
-bash-4.3#
-bash-4.3#
-bash-4.3# ./valgrind --leak-check=full --tool=memcheck -v ./test1
==31467== Memcheck, a memory error detector
==31467== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==31467== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with
-h for copyright info
==31467== Command: ./test1
==31467==
--31467-- Valgrind options:
--31467-- --leak-check=full
--31467-- --tool=memcheck
--31467-- -v
--31467-- Contents of /proc/version:
--31467-- Linux version 3.10.85-LINUX_3_10_85_SSBC_0_0_4
(anilkumar@anilkumar-dt) (gcc version 4.7.0 (Cavium Inc. Version: SDK_BUILD
build 44) ) #1 Wed Jul 25 12:43:16 IST 2018
--31467--
--31467-- Arch and hwcaps: MIPS64, BigEndian, Cavium-baseline
--31467-- Page sizes: currently 4096, max supported 65536
--31467-- Valgrind library directory:
/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind
--31467-- Reading syms from /lib64/ld-2.16.so
--31467-- Reading syms from /var/tmp/test1
--31467-- Reading syms from
/var/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind/memcheck-mips64-linux
--31467-- object doesn't have a dynamic symbol table
--31467-- Scheduler: using generic scheduler lock implementation.
--31467-- Reading suppressions file:
/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind/default.supp
==31467== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-31467-by-root-on-???
==31467== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-31467-by-root-on-???
==31467== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-31467-by-root-on-???
==31467==
==31467== TO CONTROL THIS PROCESS USING vgdb (which you probably
==31467== don't want to do, unless you know exactly what you're doing,
==31467== or are doing some strange experiment):
==31467==
/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind/../../bin/vgdb
--pid=31467 ...command...
==31467==
==31467== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==31467== /path/to/gdb ./test1
==31467== and then give GDB the following command
==31467== target remote |
/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind/../../bin/vgdb
--pid=31467
==31467== --pid is optional if only one valgrind process is running
==31467==
--31467-- REDIR: 0x401ce00 (ld.so.1:strlen) redirected to 0x5810fdd4
(vgPlain_mips64_linux_REDIR_FOR_strlen)
--31467-- REDIR: 0x401ca80 (ld.so.1:index) redirected to 0x5810fdb0
(vgPlain_mips64_linux_REDIR_FOR_index)
--31467-- Reading syms from
/var/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind/vgpreload_core-mips64-linux.so
--31467-- Reading syms from
/var/tmp/bin/lib/home/rajesh/Valgrind/valgrind_bins/lib/valgrind/vgpreload_memcheck-mips64-linux.so
--31467-- REDIR: 0x401d930 (ld.so.1:mempcpy) redirected to 0x4051268
(mempcpy)
--31467-- REDIR: 0x401d2e0 (ld.so.1:bcmp) redirected to 0x404f878 (bcmp)
--31467-- REDIR: 0x401da40 (ld.so.1:memcpy) redirected to 0x404e878 (memcpy)
--31467-- Reading syms from /lib64/libc-2.16.so
--31467-- REDIR: 0x4111310 (libc.so.6:rindex) redirected to 0x404adc0
(rindex)
==31467== Invalid read of size 8
==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so)
==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so)
==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so)
==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so)
==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so)
==31467== Address 0xffffffffffff9000 is not stack'd, malloc'd or
(recently) free'd
==31467==
==31467==
==31467== Process terminating with default action of signal 10 (SIGBUS)
==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so)
==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so)
==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so)
==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so)
==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so)
==31467== Invalid read of size 4
==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so)
==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so)
==31467== Address 0xffffffffffff8900 is not stack'd, malloc'd or
(recently) free'd
==31467==
==31467==
==31467== Process terminating with default action of signal 10 (SIGBUS)
==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so)
==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so)
==31467==
==31467== HEAP SUMMARY:
==31467== in use at exit: 0 bytes in 0 blocks
==31467== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==31467==
==31467== All heap blocks were freed -- no leaks are possible
==31467==
==31467== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==31467==
==31467== 1 errors in context 1 of 2:
==31467== Invalid read of size 4
==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so)
==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so)
==31467== Address 0xffffffffffff8900 is not stack'd, malloc'd or
(recently) free'd
==31467==
==31467==
==31467== 1 errors in context 2 of 2:
==31467== Invalid read of size 8
==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so)
==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so)
==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so)
==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so)
==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so)
==31467== Address 0xffffffffffff9000 is not stack'd, malloc'd or
(recently) free'd
==31467==
==31467== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Bus error
-bash-4.3#
-bash-4.3#
-bash-4.3#
-bash-4.3#
-bash-4.3#
-bash-4.3#
-bash-4.3# ./valgrind --leak-check=full --tool=memcheck ./test1
==31517== Memcheck, a memory error detector
==31517== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==31517== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==31517== Command: ./test1
==31517==
==31517== Invalid read of size 8
==31517== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so)
==31517== by 0x40A8C8C: _init (in /lib64/libc-2.16.so)
==31517== by 0x40129D8: call_init (in /lib64/ld-2.16.so)
==31517== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so)
==31517== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so)
==31517== Address 0xffffffffffff9000 is not stack'd, malloc'd or
(recently) free'd
==31517==
==31517==
==31517== Process terminating with default action of signal 10 (SIGBUS)
==31517== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so)
==31517== by 0x40A8C8C: _init (in /lib64/libc-2.16.so)
==31517== by 0x40129D8: call_init (in /lib64/ld-2.16.so)
==31517== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so)
==31517== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so)
==31517== Invalid read of size 4
==31517== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so)
==31517== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so)
==31517== Address 0xffffffffffff8900 is not stack'd, malloc'd or
(recently) free'd
==31517==
==31517==
==31517== Process terminating with default action of signal 10 (SIGBUS)
==31517== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so)
==31517== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so)
==31517==
==31517== HEAP SUMMARY:
==31517== in use at exit: 0 bytes in 0 blocks
==31517== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==31517==
==31517== All heap blocks were freed -- no leaks are possible
==31517==
==31517== For counts of detected and suppressed errors, rerun with: -v
==31517== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Bus error
-bash-4.3#
-bash-4.3#
-bash-4.3# ls
EmWebPipe bin etc_backup ip6_radvdpipe
reboot_log snmpd.log test1
EmWebTxtCfgWakeup consolepipe ip6_ndpipe lib
ripIntfPipe test valgrind
-bash-4.3#
Could somebody please help me to understand what the output of valgrind is
saying and why this is not showing proper output ?
Thanks,
Rajesh
|
|
From: John R. <jr...@bi...> - 2018-11-22 14:49:43
|
> ==31467== Process terminating with default action of signal 10 (SIGBUS) > ==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so <http://libc-2.16.so>) > ==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so <http://libc-2.16.so>) > ==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so <http://ld-2.16.so>) > ==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so <http://ld-2.16.so>) > ==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so <http://ld-2.16.so>) > ==31467== Invalid read of size 4 > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) > ==31467== Address 0xffffffffffff8900 is not stack'd, malloc'd or (recently) free'd > ==31467== > ==31467== > ==31467== Process terminating with default action of signal 10 (SIGBUS) > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) The code in main() never was executed. _dl_start_user is a glibc routine which runs before the first instruction of main(). The SIGBUS from trying to fetch from address 0xffffffffffff8900 terminated the program before main(). |
|
From: rajesh s. <inf...@gm...> - 2018-11-22 16:23:51
|
Hi John Reiser, Thanks for reply and information. I am new with this valgrind and glibc library. I am not able to understand how to resolve this issue. Is this issue dependent on libc library or some other issue means why this terminated before main() function ? Could you please help me about how to resolve this issue ? I would like to say thanks for your help. Thanks, Rajesh On Thu, Nov 22, 2018 at 8:20 PM John Reiser <jr...@bi...> wrote: > > ==31467== Process terminating with default action of signal 10 (SIGBUS) > > ==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so < > http://libc-2.16.so>) > > ==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so < > http://libc-2.16.so>) > > ==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > ==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > ==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > ==31467== Invalid read of size 4 > > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > ==31467== Address 0xffffffffffff8900 is not stack'd, malloc'd or > (recently) free'd > > ==31467== > > ==31467== > > ==31467== Process terminating with default action of signal 10 (SIGBUS) > > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > > The code in main() never was executed. _dl_start_user is a glibc routine > which runs before the first instruction of main(). The SIGBUS from trying > to fetch from address 0xffffffffffff8900 terminated the program before > main(). > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: John R. <jr...@bi...> - 2018-11-22 18:45:23
|
> Could you please help me about how to resolve this issue ?
Discard the Cavium hardware, then use something that has better software support;
even MIPS-R3000 series. From the page
http://valgrind.10908.n7.nabble.com/Why-valgrind-could-not-be-used-on-cavium-octeon3-td57531.html
you can see that Cavium has had such trouble for 1.5 years, but did not care to fix it
by providing a pre-built valgrind that runs on their boards. No user group,
no Field Application Engineer responded. The value of a CPU is proportional
to the support for the environment to develop software that runs on it.
For the past several years valgrind (memcheck) has been a requirement.
Buy support from Code Sourcery CodeBench.
The page https://www.mentor.com/embedded-software/semiconductors/
says that Cavium CN38xx, CN58xx, and CN68xx are supported MIP64 architectures.
Go to school to learn computer organization and operation.
Not recognizing and understanding SIGBUS is a clue that
probably there is much to learn.
|
|
From: Petar J. <mip...@gm...> - 2018-11-22 23:39:33
|
On Thu, Nov 22, 2018 at 5:24 PM rajesh singh <inf...@gm...> wrote: > > Hi John Reiser, > > Thanks for reply and information. > > > I am new with this valgrind and glibc library. I am not able to understand how to resolve this issue. > Is this issue dependent on libc library or some other issue means why this terminated before main() function ? > > Could you please help me about how to resolve this issue ? > > I would like to say thanks for your help. > > Thanks, > Rajesh > > On Thu, Nov 22, 2018 at 8:20 PM John Reiser <jr...@bi...> wrote: >> >> > ==31467== Process terminating with default action of signal 10 (SIGBUS) >> > ==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so <http://libc-2.16.so>) >> > ==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so <http://libc-2.16.so>) >> > ==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> > ==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> > ==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> > ==31467== Invalid read of size 4 >> > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> > ==31467== Address 0xffffffffffff8900 is not stack'd, malloc'd or (recently) free'd >> > ==31467== >> > ==31467== >> > ==31467== Process terminating with default action of signal 10 (SIGBUS) >> > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so <http://ld-2.16.so>) >> >> The code in main() never was executed. _dl_start_user is a glibc routine >> which runs before the first instruction of main(). The SIGBUS from trying >> to fetch from address 0xffffffffffff8900 terminated the program before main(). >> >> There is a daily buildbot that runs Valgrind on Cavium boards, and as of today, all tests pass. Here is a log from the yesterday's testing: Testing Valgrind on: cavium-02 - mips64r2 BE Linux 4.1.0-dirty glibc 2.13 27fe223 Add support for Iop_{Sar,Shr}8 on ppc. --expensive-definedness-checks=yes needs them. VEX/priv/host_ppc_isel.c == 625 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == So it is either to your toolchain or the system. It would not hurt if you updated your toolchain and the system itself. P. |
|
From: rajesh s. <inf...@gm...> - 2019-01-02 07:27:18
|
Hi All, I reached to Cavium toolchain team for this issues but got a response saying that they got the binaries from valgrind and included it as part of SDK . Could someone from valgrind team provide binaries for CN70XX and if possible provide the details steps to build the valgrind for our mips architecture with CAVIUM tool chain ? I would like to say thanks for all your support. Thanks, Rajesh On Fri, Nov 23, 2018 at 5:09 AM Petar Jovanovic <mip...@gm...> wrote: > On Thu, Nov 22, 2018 at 5:24 PM rajesh singh <inf...@gm...> > wrote: > > > > Hi John Reiser, > > > > Thanks for reply and information. > > > > > > I am new with this valgrind and glibc library. I am not able to > understand how to resolve this issue. > > Is this issue dependent on libc library or some other issue means why > this terminated before main() function ? > > > > Could you please help me about how to resolve this issue ? > > > > I would like to say thanks for your help. > > > > Thanks, > > Rajesh > > > > On Thu, Nov 22, 2018 at 8:20 PM John Reiser <jr...@bi...> > wrote: > >> > >> > ==31467== Process terminating with default action of signal 10 > (SIGBUS) > >> > ==31467== at 0x40B7EE4: __ctype_init (in /lib64/libc-2.16.so < > http://libc-2.16.so>) > >> > ==31467== by 0x40A8C8C: _init (in /lib64/libc-2.16.so < > http://libc-2.16.so>) > >> > ==31467== by 0x40129D8: call_init (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > >> > ==31467== by 0x4012BC8: _dl_init (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > >> > ==31467== by 0x400328C: _dl_start_user (in /lib64/ld-2.16.so < > http://ld-2.16.so>) > >> > ==31467== Invalid read of size 4 > >> > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so > <http://ld-2.16.so>) > >> > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so > <http://ld-2.16.so>) > >> > ==31467== Address 0xffffffffffff8900 is not stack'd, malloc'd or > (recently) free'd > >> > ==31467== > >> > ==31467== > >> > ==31467== Process terminating with default action of signal 10 > (SIGBUS) > >> > ==31467== at 0x4019508: __dl_runtime_resolve (in /lib64/ld-2.16.so > <http://ld-2.16.so>) > >> > ==31467== by 0x40192D8: _dl_runtime_resolve (in /lib64/ld-2.16.so > <http://ld-2.16.so>) > >> > >> The code in main() never was executed. _dl_start_user is a glibc > routine > >> which runs before the first instruction of main(). The SIGBUS from > trying > >> to fetch from address 0xffffffffffff8900 terminated the program before > main(). > >> > >> > > There is a daily buildbot that runs Valgrind on Cavium boards, and as > of today, all tests pass. > Here is a log from the yesterday's testing: > > Testing Valgrind on: > cavium-02 - mips64r2 BE Linux 4.1.0-dirty glibc 2.13 > 27fe223 Add support for Iop_{Sar,Shr}8 on ppc. > --expensive-definedness-checks=yes needs them. > VEX/priv/host_ppc_isel.c > > == 625 tests, 0 stderr failures, 0 stdout failures, 0 stderrB > failures, 0 stdoutB failures, 0 post failures == > > So it is either to your toolchain or the system. It would not hurt if > you updated your toolchain and the system itself. > > P. > |
|
From: Petar J. <mip...@gm...> - 2019-01-11 11:30:13
|
Hi Rajesh, Valgrind does not provide binary executables but sources. README.mips in the root folder has information how to build Valgrind for MIPS architecture. Regards, Petar |