You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
|
3
|
|
4
(1) |
5
(1) |
6
(5) |
7
|
8
|
9
|
10
|
|
11
|
12
|
13
|
14
(3) |
15
(2) |
16
(3) |
17
|
|
18
|
19
(2) |
20
(7) |
21
(2) |
22
(7) |
23
|
24
|
|
25
(2) |
26
|
27
|
28
(1) |
29
|
30
(2) |
|
|
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: 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: 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 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: Andreas A. <ar...@so...> - 2018-11-22 12:47:00
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=ddfc274b24a1ae3b57166ada1fe97acb433b9b79 commit ddfc274b24a1ae3b57166ada1fe97acb433b9b79 Author: Andreas Arnez <ar...@li...> Date: Thu Jul 26 16:35:24 2018 +0200 s390x: More fixes for z13 support This patch addresses the following: * Fix the implementation of LOCGHI. Previously Valgrind performed 32-bit sign extension instead of 64-bit sign extension on the immediate value. * Advertise VXRS in HWCAP. If no VXRS are advertised, but the program uses vector registers, this could cause problems with a glibc built with "-march=z13". Diff: --- NEWS | 1 + VEX/priv/guest_s390_toIR.c | 2 +- coregrind/m_initimg/initimg-linux.c | 6 +++--- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 2fa2c86..8b6d4b3 100644 --- a/NEWS +++ b/NEWS @@ -50,6 +50,7 @@ where XXXXXX is the bug number as listed below. 400490 s390x: VRs allocated as if separate from FPRs 400491 s390x: Operand of LOCH treated as unsigned integer 397187 z13 vector register support for vgdb gdbserver +401277 More bugs in z13 support Release 3.14.0 (9 October 2018) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/VEX/priv/guest_s390_toIR.c b/VEX/priv/guest_s390_toIR.c index 9c4d79b..50a5a41 100644 --- a/VEX/priv/guest_s390_toIR.c +++ b/VEX/priv/guest_s390_toIR.c @@ -16325,7 +16325,7 @@ static const HChar * s390_irgen_LOCGHI(UChar r1, UChar m3, UShort i2, UChar unused) { next_insn_if(binop(Iop_CmpEQ32, s390_call_calculate_cond(m3), mkU32(0))); - put_gpr_dw0(r1, mkU64((UInt)(Int)(Short)i2)); + put_gpr_dw0(r1, mkU64((ULong)(Long)(Short)i2)); return "locghi"; } diff --git a/coregrind/m_initimg/initimg-linux.c b/coregrind/m_initimg/initimg-linux.c index 61cc458..8a7f0d0 100644 --- a/coregrind/m_initimg/initimg-linux.c +++ b/coregrind/m_initimg/initimg-linux.c @@ -699,9 +699,9 @@ Addr setup_client_stack( void* init_sp, } # elif defined(VGP_s390x_linux) { - /* Advertise hardware features "below" TE only. TE and VXRS - (and anything above) are not supported by Valgrind. */ - auxv->u.a_val &= VKI_HWCAP_S390_TE - 1; + /* Advertise hardware features "below" TE and VXRS. TE itself + and anything above VXRS is not supported by Valgrind. */ + auxv->u.a_val &= (VKI_HWCAP_S390_TE - 1) | VKI_HWCAP_S390_VXRS; } # elif defined(VGP_arm64_linux) { |
|
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: Brenda B. <bj...@mo...> - 2018-11-22 01:17:10
|
There are three bugs for setns in the bugtracker: 368923 valgrind general js...@ac... REPO --- WARNING: unhandled arm64-linux syscall: 268 (setns) 07:00:50 369031 valgrind general js...@ac... RESO DUPL WARNING: unhandled amd64-linux syscall: 308 (setns) Wed 03:08 343099 valgrind memcheck js...@ac... REPO --- Linux setns syscall wrapper missing, unhandled syscall: 308 07:00:50 Well there were three before I messed with it ... 368923 is for arm64 architecture and I didn't touch it. 343099 has a patch (now it has two patches to choose from). 369031 seemed to be a duplicate of 343099. So I marked it as a duplicate of 343099. However today I looked in docs/internals/3_12_BUGSTATUS.txt and I see that 369031 is listed there but 343099 is not. So how shall I resolve this? I can edit 3_12_BUGSTATUS.txt to point to the other bug number, or I can try to edit the bugs in the bug tracker so that 343099 is the duplicate, and the patches are attached to 369031. bjb On Thu, Mar 1, 2018 at 2:15 AM Tom Hughes <to...@co...> wrote: > > On 01/03/18 05:41, Peter Zelezny wrote: > > > I found adding this stub for setns() 308 syscall very useful. Please > > consider for inclusion in git. > > Please open a bug and attach the patch - even better look for a bug > asking for this which I think exists and attach it. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |