You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
(3) |
3
(14) |
4
(33) |
5
(1) |
6
(11) |
7
(4) |
8
(3) |
|
9
|
10
(13) |
11
(23) |
12
(4) |
13
(4) |
14
(7) |
15
(1) |
|
16
|
17
(29) |
18
(24) |
19
(5) |
20
(8) |
21
(8) |
22
(3) |
|
23
|
24
(1) |
25
(9) |
26
(4) |
27
(8) |
28
(7) |
29
(5) |
|
30
(6) |
31
(3) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2005-10-14 12:31:34
|
> --12266:1:main Print the preamble... > ==12266== Nulgrind, a binary JIT-compiler. > ==12266== Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas > Nethercote. ==12266== Segmentation fault > root@10.70.0.222:/valgrind# Did you fake up the contents of VEX/priv/main/vex_svnversion.h with a NULL string? If yes, try this. Then maybe you will advance to 'illegal instruction'. J sewardj@imac:~/VgTRUNK/trunk$ cat VEX/priv/main/vex_svnversion.h "1419" sewardj@imac:~/VgTRUNK/trunk$ |
|
From: Javier C. <jca...@sb...> - 2005-10-14 12:21:56
|
Here it is. Thanks root@10.70.0.222:/valgrind# valgrind --tool=none -d -d -v -v /bin/ls -l --12266:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --12266:1:launcher tool 'none' requested --12266:1:launcher launching /usr/local/lib/valgrind/none --12266:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging re quested --12266:1:main Welcome to Valgrind version 3.1.SVN debug logging --12266:1:main Checking current stack is plausible --12266:1:main Checking initial stack was noted --12266:1:main Starting the address space manager --12266:2:aspacem sp_at_startup = 0x007FFFFD40 (supplied) --12266:2:aspacem minAddr = 0x0004000000 (computed) --12266:2:aspacem maxAddr = 0x007FFFEFFF (computed) --12266:2:aspacem cStart = 0x0004000000 (computed) --12266:2:aspacem vStart = 0x0042000000 (computed) --12266:2:aspacem suggested_clstack_top = 0x007EFFFFFF (computed) --12266:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segnames) --12266:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --12266:2:aspacem 1: 0004000000-0041FFFFFF 992m --12266:2:aspacem 2: RSVN 0042000000-0042000FFF 4096 ----- SmFixed --12266:2:aspacem 3: 0042001000-007FFFEFFF 991m --12266:2:aspacem 4: RSVN 007FFFF000-00FFFFFFFF 2048m ----- SmFixed --12266:2:aspacem >>> --12266:2:aspacem Reading /proc/self/maps --12266:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (11 seg ments, 1 segnames) --12266:2:aspacem ( 0) /usr/local/lib/valgrind/none --12266:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --12266:2:aspacem 1: 0004000000-0041FFFFFF 992m --12266:2:aspacem 2: RSVN 0042000000-0042000FFF 4096 ----- SmFixed --12266:2:aspacem 3: 0042001000-006FFFFFFF 735m --12266:2:aspacem 4: FILE 0070000000-0070138FFF 1282048 r-x-- d=0x00A i=125 02998 o=0 (0) --12266:2:aspacem 5: 0070139000-0070148FFF 65536 --12266:2:aspacem 6: FILE 0070149000-0070149FFF 4096 rwx-- d=0x00A i=125 02998 o=1282048 (0) --12266:2:aspacem 7: ANON 007014A000-007079AFFF 6623232 rwx-- --12266:2:aspacem 8: 007079B000-007FFEAFFF 248m --12266:2:aspacem 9: ANON 007FFEB000-007FFFFFFF 86016 rw--- --12266:2:aspacem 10: RSVN 0080000000-00FFFFFFFF 2048m ----- SmFixed --12266:2:aspacem >>> --12266:1:main Address space manager is running --12266:1:main Starting the dynamic memory manager --12266:1:mallocfr newSuperblock at 0x42001000 (pszB 1048560) owner VALGRIND/too l --12266:1:main Dynamic memory manager is running --12266:1:main Getting stage1's name --12266:1:main Split up command line --12266:1:main Preprocess command line opts --12266:1:main Loading client --12266:1:main Setup client env --12266:2:main preload_string: --12266:2:main "/usr/local/lib/valgrind/vgpreload_core.so" --12266:1:main Setup client stack --12266:2:main PPC32 cache line size 32 (type 19) --12266:2:main PPC32 cache line size 32 (type 20) --12266:2:main PPC32 hwcaps: 0x84000000 --12266:2:main PPC32 AltiVec support: 0 --12266:2:main Client info: initial_IP=0x4010984 initial_SP=0x7EFFFD80 brk _base=0x1002A000 --12266:1:main Setup client data (brk) segment --12266:1:main Setup file descriptors --12266:1:main Create fake /proc/<pid>/cmdline --12266:1:main Initialise the tool part 1 (pre_clo_init) --12266:1:main Print help and quit, if requested --12266:1:main Process Valgrind's command line options, setup logging --12266:1:main Print the preamble... ==12266== Nulgrind, a binary JIT-compiler. ==12266== Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nethercote. ==12266== Segmentation fault root@10.70.0.222:/valgrind# -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Julian Seward Sent: Wednesday, October 12, 2005 8:18 PM To: val...@li... Subject: Re: [Valgrind-users] Valgrind 3.0 repository on ppc32 > The code repository page mentions the 3.0 line is not ready for ppc32 > yet but the posting dated June 2005. It's been three months since then, > so what is the status of the ppc support? Improving and under active development. The main shortcoming is that Altivec is not really usable yet. There are also performance issues. Both of these are being worked on. Apart from that all the tools work (cachegrind, massif, memcheck) and work well enough to be usable. It gets worked on regularly on a G5 and on a Mac Mini, both running YDL4, and it also works on an old iMac running SuSE 10.0. > I am trying on an amcc 440gp machine running a 2.6.10 kernel but getting > a segmentation fault as shown below: Hmm. Can you send the result of valgrind --tool=none -d -d -v -v /bin/ls -l J ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Shands, W. <wal...@in...> - 2005-10-13 22:35:47
|
Does valgrind support OpenMP applications? =20 I always get the error: "OMP abort: System unable to allocate necessary resources for monitor thread. Try decreasing the number of threads in use simultaneously." =20 when I try to use valgrind (3.0.1) memcheck on my openmp application. =20 Walter |
|
From: Jaskaran S. <jas...@pe...> - 2005-10-13 14:22:13
|
Hi, Does valgrind provide a means of selectively turning heap checking ON = and OFF programmatically ? Something like: HeapChecker.start(); doSomething(); HeapChecker.stop(); so that the generated report contains leaks, if any, in doSomething(); I = am looking to integrate valgrind with my unit test framework but I do = not want the complete test harness to run under valgrind as that can be = prohibitive. Regards, Jaskaran |
|
From: Julian S. <js...@ac...> - 2005-10-13 01:20:33
|
> The code repository page mentions the 3.0 line is not ready for ppc32 > yet but the posting dated June 2005. It's been three months since then, > so what is the status of the ppc support? Improving and under active development. The main shortcoming is that Altivec is not really usable yet. There are also performance issues. Both of these are being worked on. Apart from that all the tools work (cachegrind, massif, memcheck) and work well enough to be usable. It gets worked on regularly on a G5 and on a Mac Mini, both running YDL4, and it also works on an old iMac running SuSE 10.0. > I am trying on an amcc 440gp machine running a 2.6.10 kernel but getting > a segmentation fault as shown below: Hmm. Can you send the result of valgrind --tool=none -d -d -v -v /bin/ls -l J |
|
From: Javier C. <jca...@sb...> - 2005-10-13 01:02:41
|
Hello
The code repository page mentions the 3.0 line is not ready for ppc32
yet but the posting dated June 2005. It's been three months since then,
so what is the status of the ppc support?
I am trying on an amcc 440gp machine running a 2.6.10 kernel but getting
a segmentation fault as shown below:
root@10.70.0.222:/valgrind# valgrind --tool=memcheck /bin/ls -l
==12263== Memcheck, a memory error detector.
==12263== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et
al.
==12263== Segmentation fault
root@10.70.0.222:/valgrind # uname -a
Linux 10.70.0.222 2.6.10_dev-440gp_eval #5 Mon Oct 10 13:41:03 CDT
2005 ppc GNU/
Linux
root@10.70.0.222:/valgrind-2.3.0.CVS-ppc.new/valgrind#
Thanks
|
|
From: Jeff M. <je...@in...> - 2005-10-12 19:00:25
|
> The .s example is useful. However, can you send a .c example + > details of what gcc I need to cause it to generate such code? > I'd like to see the wider context of the problem. The c file is attached. The problem shows up with gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) and gcc version 4.0.2 (Debian 4.0.2-2) looks to produce similar code. I compiled it with just: gcc test.c -o test -Jeff |
|
From: Julian S. <js...@ac...> - 2005-10-12 09:54:53
|
> Is this problem fixable? Maybe. The .s example is useful. However, can you send a .c example + details of what gcc I need to cause it to generate such code? I'd like to see the wider context of the problem. J |
|
From: Tom H. <to...@co...> - 2005-10-12 06:17:23
|
In message <20051012022838.GA31034@debian>
Jeff Muizelaar <je...@in...> wrote:
> With the attached example valgrind 3.0.1 wrongly complains:
>
> ==2888== Conditional jump or move depends on uninitialised value(s)
> ==2888== at 0x804835C: (within /home/jrmuizel/test/main)
> ==2888== by 0x80482B0: ??? (start.S:119)
>
> The problem appears to be provoked by valgrind not
> properly tracking the v-bits through 'add's.
The tracking done is quick-n-dirty normally and not perfect - there is
a more accurate version that is sometimes done if memcheck sees certain
constants in the same block of code.
> replacing 'add %eax, %eax' in the attached program with 'shl $1, %eax'
> makes the error go away.
>
> The example is a cleaned up version of some code produced by gcc and was
> producing false positives in real code.
>
> Is this problem fixable?
Julian will need to answer that, but please file a bug for this.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeff M. <je...@in...> - 2005-10-12 02:28:50
|
With the attached example valgrind 3.0.1 wrongly complains: ==2888== Conditional jump or move depends on uninitialised value(s) ==2888== at 0x804835C: (within /home/jrmuizel/test/main) ==2888== by 0x80482B0: ??? (start.S:119) The problem appears to be provoked by valgrind not properly tracking the v-bits through 'add's. replacing 'add %eax, %eax' in the attached program with 'shl $1, %eax' makes the error go away. The example is a cleaned up version of some code produced by gcc and was producing false positives in real code. Is this problem fixable? Thanks, -Jeff |
|
From: Julian S. <js...@ac...> - 2005-10-11 18:43:28
|
> > It fixed the problem. Valgrind now detects the lost memory. > > Thank you very much for your help. > > Great. The only question now is what the permanent fix should > be - maybe we should just use libc.so.* to match C libraries in > general? Sounds good to me. Except, I guess it should in that case be libc.so*, yes? > It's probably a good idea if you raise a bug for this so we don't > forget about it. Definitely. J |
|
From: Tom H. <to...@co...> - 2005-10-11 18:05:53
|
In message <200...@ad...>
fr...@be... wrote:
> Quoting Tom Hughes <to...@co...>:
>
> > In message <200...@ad...>
> > fr...@be... wrote:
> >
> >> --18300-- Reading syms from /lib/libuClibc-0.9.28.so (0x4016000)
> >> --18300-- object doesn't have a symbol table
> >> --18300-- Just loaded /lib/libuClibc-0.9.28.so (soname=libc.so.0),
> >> --18300-- resolving any unresolved redirs with it
> >> --18300-- Finished resolving
> >
> > There's the problem - the soname doesn't match so none of the
> > redirects has been processed.
> >
> > As a quick hack you can edit coregrind/m_replacemalloc/vg_replace_malloc.c
> > and change this line:
> >
> > #define m_libc_dot_so_dot_6 libcZdsoZd6 // libc.so.6
> >
> > to this:
> >
> > #define m_libc_dot_so_dot_6 libcZdsoZd0 // libc.so.0
> >
> > and see if that works any better.
>
> It fixed the problem. Valgrind now detects the lost memory.
> Thank you very much for your help.
Great. The only question now is what the permanent fix should
be - maybe we should just use libc.so.* to match C libraries in
general?
It's probably a good idea if you raise a bug for this so we don't
forget about it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-11 17:57:33
|
> Can/Should i also do a simple replace on these? Yes/Yes. J |
|
From: <fr...@be...> - 2005-10-11 17:31:12
|
Quoting Tom Hughes <to...@co...>:
> In message <200...@ad...>
> fr...@be... wrote:
>
>> --18300-- Reading syms from /lib/libuClibc-0.9.28.so (0x4016000)
>> --18300-- object doesn't have a symbol table
>> --18300-- Just loaded /lib/libuClibc-0.9.28.so (soname=libc.so.0),
>> --18300-- resolving any unresolved redirs with it
>> --18300-- Finished resolving
>
> There's the problem - the soname doesn't match so none of the
> redirects has been processed.
>
> As a quick hack you can edit coregrind/m_replacemalloc/vg_replace_malloc.c
> and change this line:
>
> #define m_libc_dot_so_dot_6 libcZdsoZd6 // libc.so.6
>
> to this:
>
> #define m_libc_dot_so_dot_6 libcZdsoZd0 // libc.so.0
>
> and see if that works any better.
It fixed the problem. Valgrind now detects the lost memory.
Thank you very much for your help.
There were other places where this string was used:
frank@linux:~/valgrind> find -type f | xargs grep libcZdsoZd6 | grep -v svn |
grep -v Binary
./coregrind/m_redir.c: _vgi_libcZdsoZd6__ZdlPv --> libc.so.6:_ZdlPv
./coregrind/m_replacemalloc/vg_replace_malloc.c: return
VG_REPLACE_FUNCTION(libcZdsoZd6,malloc) (new_size); \
./coregrind/m_replacemalloc/vg_replace_malloc.c:
VG_REPLACE_FUNCTION(libcZdsoZd6,free)(ptrV); \
./coregrind/m_replacemalloc/vg_replace_malloc.c: return
VG_REPLACE_FUNCTION(libcZdsoZd6,memalign)(VKI_PAGE_SIZE, size); \
./coregrind/m_replacemalloc/vg_replace_malloc.c: mem =
VG_REPLACE_FUNCTION(libcZdsoZd6,memalign)(alignment, size); \
./memcheck/mac_replace_strmem.c:#define m_libc_so_6 libcZdsoZd6
// libc.so.6
Can/Should i also do a simple replace on these?
Regards,
Frank
|
|
From: Tom H. <to...@co...> - 2005-10-11 17:03:51
|
In message <200...@ad...>
fr...@be... wrote:
> --18300-- Reading syms from /lib/libuClibc-0.9.28.so (0x4016000)
> --18300-- object doesn't have a symbol table
> --18300-- Just loaded /lib/libuClibc-0.9.28.so (soname=libc.so.0),
> --18300-- resolving any unresolved redirs with it
> --18300-- Finished resolving
There's the problem - the soname doesn't match so none of the
redirects has been processed.
As a quick hack you can edit coregrind/m_replacemalloc/vg_replace_malloc.c
and change this line:
#define m_libc_dot_so_dot_6 libcZdsoZd6 // libc.so.6
to this:
#define m_libc_dot_so_dot_6 libcZdsoZd0 // libc.so.0
and see if that works any better.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <fr...@be...> - 2005-10-11 16:56:46
|
Quoting Tom Hughes <to...@co...>: > In message <200...@ac...> > Julian Seward <js...@ac...> wrote: >> > > Clearly it has failed to intercept malloc. Run with -v and post >> > > the result. >> >> That might be because the soname of the uclibc .so is different >> from that of the regular libc.so. Interception is based on >> (soname,functionname) pairs. Can you find that information out? > > Running with --trace-redir=yes will show that. I was thinking that -v > would show it when I asked for that. Here's a rerun with --trace-redir=yes. bash-3.00$ valgrind -v --trace-redir=yes /a.out ==18300== Memcheck, a memory error detector. ==18300== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==18300== Using LibVEX rev 1418, a library for dynamic binary translation. ==18300== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==18300== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==18300== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==18300== --18300-- Valgrind library directory: /usr/local/lib/valgrind --18300-- Command line --18300-- /a.out --18300-- Startup, with flags: --18300-- -v --18300-- --trace-redir=yes --18300-- Contents of /proc/version: --18300-- Linux version 2.6.8-24.18-smp (geeko@buildhost) (gcc version 3.3.4 (pre 3.3.5 20040809)) #1 SMP Fri Aug 19 11:56:28 UTC 2005 --18300-- REDIR sym to addr: soname:ld-linux.so.2:_dl_sysinfo_int80 to 0xB001B793 --18300-- Reading syms from /lib/ld-uClibc-0.9.28.so (0x4000000) --18300-- object doesn't have a symbol table --18300-- Just loaded /lib/ld-uClibc-0.9.28.so (soname=ld-uClibc.so.0), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving --18300-- Reading syms from /a.out (0x8048000) --18300-- Just loaded /a.out (soname=(null)), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving --18300-- Reading syms from /usr/local/lib/valgrind/memcheck (0xB0000000) --18300-- object doesn't have a dynamic symbol table --18300-- Just loaded /usr/local/lib/valgrind/memcheck (soname=(null)), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving --18300-- Reading suppressions file: /usr/local/lib/valgrind/default.supp ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40029EF: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) --18300-- Reading syms from /usr/local/lib/valgrind/vgpreload_core.so (0x4007000) --18300-- Just loaded /usr/local/lib/valgrind/vgpreload_core.so (soname=vgpreload_core.so), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving --18300-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck.so (0x4009000) --18300-- REDIR sym to addr: soname:libstdc++*:builtin_new to 0x400A92D --18300-- REDIR sym to addr: soname:libc.so.6:strrchr to 0x400C100 --18300-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_delete to 0x400B8A9 --18300-- REDIR sym to addr: soname:ld-linux.so.2:strchr to 0x400C198 --18300-- REDIR sym to addr: soname:libc.so.6:strncat to 0x400C2F0 --18300-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_new to 0x400AECF --18300-- REDIR sym to addr: soname:libc.so.6:__builtin_new to 0x400AB5B --18300-- REDIR sym to addr: soname:libc.so.6:_ZnajRKSt9nothrow_t to 0x400B25A --18300-- REDIR sym to addr: soname:libc.so.6:strchrnul to 0x400CAC0 --18300-- REDIR sym to addr: soname:libc.so.6:_ZdlPvRKSt9nothrow_t to 0x400B7A1 --18300-- REDIR sym to addr: soname:libc.so.6:stpcpy to 0x400C850 --18300-- REDIR sym to addr: soname:libc.so.6:_ZdlPv to 0x400B699 --18300-- REDIR sym to addr: soname:libc.so.6:strncpy to 0x400C4DC --18300-- REDIR sym to addr: soname:libc.so.6:bcmp to 0x400C820 --18300-- REDIR sym to addr: soname:libc.so.6:memset to 0x400CA54 --18300-- REDIR sym to addr: soname:ld-linux-x86-64.so.2:strchr to 0x400C1B8 --18300-- REDIR sym to addr: soname:libc.so.6:_ZnwjRKSt9nothrow_t to 0x400AE2C --18300-- REDIR sym to addr: soname:ld-linux.so.2:rindex to 0x400C150 --18300-- REDIR sym to addr: soname:libc.so.6:memalign to 0x400BCC8 --18300-- REDIR sym to addr: soname:libc.so.6:realloc to 0x400BBE8 --18300-- REDIR sym to addr: soname:libc.so.6:_ZdaPv to 0x400B9B1 --18300-- REDIR sym to addr: soname:libc.so.6:memmove to 0x400CA74 --18300-- REDIR sym to addr: soname:libc.so.6:strchr to 0x400C178 --18300-- REDIR sym to addr: soname:libc.so.6:malloc_trim to 0x400BF18 --18300-- REDIR sym to addr: soname:libc.so.6:free to 0x400B381 --18300-- REDIR sym to addr: soname:libc.so.6:rawmemchr to 0x400CADC --18300-- REDIR sym to addr: soname:libstdc++*:malloc to 0x400A7E7 --18300-- REDIR sym to addr: soname:libc.so.6:strcpy to 0x400C42C --18300-- REDIR sym to addr: soname:ld-linux-x86-64.so.2:strlen to 0x400C410 --18300-- REDIR sym to addr: soname:libc.so.6:mallopt to 0x400BDAE --18300-- REDIR sym to addr: soname:libc.so.6:malloc_set_state to 0x400BF5A --18300-- REDIR sym to addr: soname:libc.so.6:_Znwj to 0x400ACCF --18300-- REDIR sym to addr: soname:libstdc++*:_ZdlPvRKSt9nothrow_t to 0x400B71D --18300-- REDIR sym to addr: soname:libc.so.6:cfree to 0x400B489 --18300-- REDIR sym to addr: soname:libstdc++*:_Znaj to 0x400B043 --18300-- REDIR sym to addr: soname:libc.so.6:__builtin_delete to 0x400B591 --18300-- REDIR sym to addr: soname:libstdc++*:free to 0x400B2FD --18300-- REDIR sym to addr: soname:ld-linux.so.2:strlen to 0x400C3F4 --18300-- REDIR sym to addr: soname:libc.so.6:index to 0x400C1D8 --18300-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_new to 0x400AF89 --18300-- REDIR sym to addr: soname:ld-linux-x86-64.so.2:stpcpy to 0x400C9A8 --18300-- REDIR sym to addr: soname:libstdc++*:_ZnajRKSt9nothrow_t to 0x400B1B7 --18300-- REDIR sym to addr: soname:ld-linux-x86-64.so.2:strcmp to 0x400C67C --18300-- REDIR sym to addr: soname:libstdc++*:_ZnwjRKSt9nothrow_t to 0x400AD89 --18300-- REDIR sym to addr: soname:libc.so.6:strncmp to 0x400C5F8 --18300-- REDIR sym to addr: soname:libc.so.6:valloc to 0x400BD8C --18300-- REDIR sym to addr: soname:libc.so.6:malloc to 0x400A88A --18300-- REDIR sym to addr: soname:libc.so.6:mallinfo to 0x400BF7B --18300-- REDIR sym to addr: soname:libstdc++*:_ZdlPv to 0x400B615 --18300-- REDIR sym to addr: soname:libc.so.6:strcat to 0x400C238 --18300-- REDIR sym to addr: soname:libstdc++*:__builtin_new to 0x400AAA1 --18300-- REDIR sym to addr: soname:libc.so.6:pvalloc to 0x400BED6 --18300-- REDIR sym to addr: soname:ld-linux.so.2:index to 0x400C1F8 --18300-- REDIR sym to addr: soname:libc.so.6:builtin_new to 0x400A9E7 --18300-- REDIR sym to addr: soname:libstdc++*:__builtin_delete to 0x400B50D --18300-- REDIR sym to addr: soname:libc.so.6:strnlen to 0x400C3B4 --18300-- REDIR sym to addr: soname:libc.so.6:memchr to 0x400C6A8 --18300-- REDIR sym to addr: soname:ld-linux-x86-64.so.2:index to 0x400C218 --18300-- REDIR sym to addr: soname:libc.so.6:calloc to 0x400BB3D --18300-- REDIR sym to addr: soname:libc.so.6:strlen to 0x400C3D8 --18300-- REDIR sym to addr: soname:libc.so.6:memcpy to 0x400C6CC --18300-- REDIR sym to addr: soname:libc.so.6:malloc_stats to 0x400BEF7 --18300-- REDIR sym to addr: soname:libc.so.6:memcmp to 0x400C7F0 --18300-- REDIR sym to addr: soname:libstdc++*:cfree to 0x400B405 --18300-- REDIR sym to addr: soname:libc.so.6:malloc_get_state to 0x400BF39 --18300-- REDIR sym to addr: soname:libc.so.6:posix_memalign to 0x400BDB8 --18300-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_delete to 0x400B825 --18300-- REDIR sym to addr: soname:libc.so.6:malloc_usable_size to 0x400BE04 --18300-- REDIR sym to addr: soname:libc.so.6:rindex to 0x400C128 --18300-- REDIR sym to addr: soname:libc.so.6:_ZdaPvRKSt9nothrow_t to 0x400BAB9 --18300-- REDIR sym to addr: soname:libc.so.6:_Znaj to 0x400B0FD --18300-- REDIR sym to addr: soname:libstdc++*:_ZdaPvRKSt9nothrow_t to 0x400BA35 --18300-- REDIR sym to addr: soname:libstdc++*:_Znwj to 0x400AC15 --18300-- REDIR sym to addr: soname:libc.so.6:strcmp to 0x400C650 --18300-- REDIR sym to addr: soname:ld-linux.so.2:stpcpy to 0x400C8FC --18300-- REDIR sym to addr: soname:libstdc++*:_ZdaPv to 0x400B92D --18300-- Just loaded /usr/local/lib/valgrind/vgpreload_memcheck.so (soname=(null)), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving ==18300== ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40022B7: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x4002306: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) --18300-- Reading syms from /lib/libgcc_s.so.1 (0x400E000) --18300-- object doesn't have a symbol table --18300-- Just loaded /lib/libgcc_s.so.1 (soname=libgcc_s.so.1), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving --18300-- Reading syms from /lib/libuClibc-0.9.28.so (0x4016000) --18300-- object doesn't have a symbol table --18300-- Just loaded /lib/libuClibc-0.9.28.so (soname=libc.so.0), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving --18300-- Reading syms from /lib/libdl-0.9.28.so (0x40A5000) --18300-- object doesn't have a symbol table --18300-- Just loaded /lib/libdl-0.9.28.so (soname=libdl.so.0), --18300-- resolving any unresolved redirs with it --18300-- Finished resolving ==18300== ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40025EA: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x400261F: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x400266E: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40032AC: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0) ==18300== ==18300== 1 errors in context 1 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40032AC: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== 1 errors in context 2 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x400266E: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== 1 errors in context 3 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x400261F: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== 1 errors in context 4 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40025EA: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== 1 errors in context 5 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40029EF: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== 2 errors in context 6 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x4002306: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== ==18300== 2 errors in context 7 of 7: ==18300== Conditional jump or move depends on uninitialised value(s) ==18300== at 0x40022B7: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==18300== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==18300== IN SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0) ==18300== ==18300== malloc/free: in use at exit: 0 bytes in 0 blocks. ==18300== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==18300== ==18300== No malloc'd blocks -- no leaks are possible. --18300-- memcheck: sanity checks: 0 cheap, 1 expensive --18300-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --18300-- memcheck: auxmaps: 0 searches, 0 comparisons --18300-- memcheck: secondaries: 7 issued (448k, 0M) --18300-- memcheck: secondaries: 7 accessible and distinguished (448k, 0M) --18300-- tt/tc: 1,562 tt lookups requiring 1,561 probes --18300-- tt/tc: 1,562 fast-cache updates, 2 flushes --18300-- translate: new 781 (15,573 -> 268,353; ratio 172:10) [0 scs] --18300-- translate: dumped 0 (0 -> ??) --18300-- translate: discarded 0 (0 -> ??) --18300-- scheduler: 44,791 jumps (bb entries). --18300-- scheduler: 0/836 major/minor sched events. --18300-- sanity: 1 cheap, 1 expensive checks. --18300-- exectx: 30,011 lists, 7 contexts (avg 0 per list) --18300-- exectx: 9 searches, 2 full compares (222 per 1000) --18300-- exectx: 0 cmp2, 25 cmp4, 0 cmpAll > I also suspect that the problem is the soname as he isn't using glibc > so the soname is probably not libc.so.6. No it isn't. bash-3.00$ ls -lF /lib/libc* lrwxrwxrwx 1 frank 200 19 Sep 19 04:30 /lib/libc.so.0 -> libuClibc-0.9.28.so -rw-r--r-- 1 frank 200 9032 Sep 19 04:30 /lib/libcrypt-0.9.28.so lrwxrwxrwx 1 frank 200 18 Sep 19 04:30 /lib/libcrypt.so.0 -> libcrypt-0.9.28.so Regards, Frank |
|
From: Julian S. <js...@ac...> - 2005-10-11 16:50:39
|
> I also suspect that the problem is the soname as he isn't using glibc > so the soname is probably not libc.so.6. At least it would be an easy fix if that were indeed the case. J |
|
From: Tom H. <to...@co...> - 2005-10-11 16:48:08
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>
> > > Clearly it has failed to intercept malloc. Run with -v and post
> > > the result.
>
> That might be because the soname of the uclibc .so is different
> from that of the regular libc.so. Interception is based on
> (soname,functionname) pairs. Can you find that information out?
Running with --trace-redir=yes will show that. I was thinking that -v
would show it when I asked for that.
I also suspect that the problem is the soname as he isn't using glibc
so the soname is probably not libc.so.6.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-11 16:28:05
|
> > Clearly it has failed to intercept malloc. Run with -v and post > > the result. That might be because the soname of the uclibc .so is different from that of the regular libc.so. Interception is based on (soname,functionname) pairs. Can you find that information out? J |
|
From: <fr...@be...> - 2005-10-11 15:58:36
|
Quoting Tom Hughes <to...@co...>: > In message <200...@ad...> > fr...@be... wrote: > >> ==16527== ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0) >> ==16527== malloc/free: in use at exit: 0 bytes in 0 blocks. >> ==16527== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. >> ==16527== For counts of detected errors, rerun with: -v >> ==16527== No malloc'd blocks -- no leaks are possible. > > Clearly it has failed to intercept malloc. Run with -v and post > the result. Hi, here's the output. bash-3.00$ valgrind -v /a.out ==17516== Memcheck, a memory error detector. ==17516== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==17516== Using LibVEX rev 1418, a library for dynamic binary translation. ==17516== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==17516== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==17516== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==17516== --17516-- Valgrind library directory: /usr/local/lib/valgrind --17516-- Command line --17516-- /a.out --17516-- Startup, with flags: --17516-- -v --17516-- Contents of /proc/version: --17516-- Linux version 2.6.8-24.18-smp (geeko@buildhost) (gcc version 3.3.4 (pre 3.3.5 20040809)) #1 SMP Fri Aug 19 11:56:28 UTC 2005 --17516-- Reading syms from /lib/ld-uClibc-0.9.28.so (0x4000000) --17516-- object doesn't have a symbol table --17516-- Reading syms from /a.out (0x8048000) --17516-- Reading syms from /usr/local/lib/valgrind/memcheck (0xB0000000) --17516-- object doesn't have a dynamic symbol table --17516-- Reading suppressions file: /usr/local/lib/valgrind/default.supp ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40029EF: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) --17516-- Reading syms from /usr/local/lib/valgrind/vgpreload_core.so (0x4007000) --17516-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck.so (0x4009000) ==17516== ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40022B7: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x4002306: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) --17516-- Reading syms from /lib/libgcc_s.so.1 (0x400E000) --17516-- object doesn't have a symbol table --17516-- Reading syms from /lib/libuClibc-0.9.28.so (0x4016000) --17516-- object doesn't have a symbol table --17516-- Reading syms from /lib/libdl-0.9.28.so (0x40A5000) --17516-- object doesn't have a symbol table ==17516== ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40025EA: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x400261F: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x400266E: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40032AC: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0) ==17516== ==17516== 1 errors in context 1 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40032AC: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== 1 errors in context 2 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x400266E: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== 1 errors in context 3 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x400261F: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== 1 errors in context 4 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40025EA: _dl_fixup (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== 1 errors in context 5 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40029EF: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== 2 errors in context 6 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x4002306: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== ==17516== 2 errors in context 7 of 7: ==17516== Conditional jump or move depends on uninitialised value(s) ==17516== at 0x40022B7: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==17516== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) ==17516== IN SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0) ==17516== ==17516== malloc/free: in use at exit: 0 bytes in 0 blocks. ==17516== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==17516== ==17516== No malloc'd blocks -- no leaks are possible. --17516-- memcheck: sanity checks: 0 cheap, 1 expensive --17516-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --17516-- memcheck: auxmaps: 0 searches, 0 comparisons --17516-- memcheck: secondaries: 7 issued (448k, 0M) --17516-- memcheck: secondaries: 7 accessible and distinguished (448k, 0M) --17516-- tt/tc: 1,562 tt lookups requiring 1,561 probes --17516-- tt/tc: 1,562 fast-cache updates, 2 flushes --17516-- translate: new 781 (15,573 -> 268,353; ratio 172:10) [0 scs] --17516-- translate: dumped 0 (0 -> ??) --17516-- translate: discarded 0 (0 -> ??) --17516-- scheduler: 44,779 jumps (bb entries). --17516-- scheduler: 0/836 major/minor sched events. --17516-- sanity: 1 cheap, 1 expensive checks. --17516-- exectx: 30,011 lists, 7 contexts (avg 0 per list) --17516-- exectx: 9 searches, 2 full compares (222 per 1000) --17516-- exectx: 0 cmp2, 25 cmp4, 0 cmpAll Regards, Frank |
|
From: Brian C. <cr...@fi...> - 2005-10-11 15:34:59
|
Looks like your valgrind cmd line isn't specifying either a tool, OR that you want to check leaks...
try running valgrind --help to check out the options and tools, then run it again with a tool
selected to see the options specific to that tool. Here's a command line I like:
valgrind --track-fds=yes --db-attach=yes --num-callers=7 --tool=memcheck --leak-check=yes
fr...@be... wrote:
> Hi,
>
> i'm using a svn-version of valgrind in a uclibc-chroot
> (uclibc-0.98).
>
> My problem is that it fails to catch memleaks.
>
> frank@linux:~> cat main.c
> int main() {
> void* bla ;
> int i;
>
> for (i = 0; i < 10; i++) {
> bla = (void*)malloc(10);
> }
> }
>
> frank@linux:~> i386-linux-gcc main.c # uclibc toolchain
> cp a.out $CHROOT
>
> In chroot:
>
> bash-3.00$ valgrind /a.out
> ==16527== Memcheck, a memory error detector.
> ==16527== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
> ==16527== Using LibVEX rev 1418, a library for dynamic binary translation.
> ==16527== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==16527== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework.
> ==16527== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
> ==16527== For more details, rerun with: -v
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x40029EF: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x40022B7: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x4002306: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x40025EA: _dl_fixup (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x400261F: _dl_fixup (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x400266E: _dl_fixup (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== Conditional jump or move depends on uninitialised value(s)
> ==16527== at 0x40032AC: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
> ==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
> ==16527==
> ==16527== ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0)
> ==16527== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==16527== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==16527== For counts of detected errors, rerun with: -v
> ==16527== No malloc'd blocks -- no leaks are possible.
>
> bash-3.00$ ldd /a.out
> ldd: can't open cache '/etc/ld.so.cache'
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40007000)
> libc.so.0 => /lib/libc.so.0 (0x4000f000)
> ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
>
> It's not statically linked.
>
> Any ideas what's wrong? When running the same program against
> the same svn-version of valgrind on my regular system i get
> this:
>
> frank@linux:~> valgrind a.out
> ==16442== Memcheck, a memory error detector.
> ==16442== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
> ==16442== Using LibVEX rev 1418, a library for dynamic binary translation.
> ==16442== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==16442== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework.
> ==16442== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
> ==16442== For more details, rerun with: -v
> ==16442==
> ==16442==
> ==16442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
> ==16442== malloc/free: in use at exit: 100 bytes in 10 blocks.
> ==16442== malloc/free: 10 allocs, 0 frees, 100 bytes allocated.
> ==16442== For counts of detected errors, rerun with: -v
> ==16442== searching for pointers to 10 not-freed blocks.
> ==16442== checked 65,620 bytes.
> ==16442==
> ==16442== LEAK SUMMARY:
> ==16442== definitely lost: 100 bytes in 10 blocks.
> ==16442== possibly lost: 0 bytes in 0 blocks.
> ==16442== still reachable: 0 bytes in 0 blocks.
> ==16442== suppressed: 0 bytes in 0 blocks.
> ==16442== Use --leak-check=full to see details of leaked memory.
>
> TIA Frank
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
|
|
From: Tom H. <to...@co...> - 2005-10-11 15:31:37
|
In message <200...@ad...>
fr...@be... wrote:
> ==16527== ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0)
> ==16527== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==16527== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==16527== For counts of detected errors, rerun with: -v
> ==16527== No malloc'd blocks -- no leaks are possible.
Clearly it has failed to intercept malloc. Run with -v and post
the result.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <fr...@be...> - 2005-10-11 15:25:32
|
Hi,
i'm using a svn-version of valgrind in a uclibc-chroot
(uclibc-0.98).
My problem is that it fails to catch memleaks.
frank@linux:~> cat main.c
int main() {
void* bla ;
int i;
for (i = 0; i < 10; i++) {
bla = (void*)malloc(10);
}
}
frank@linux:~> i386-linux-gcc main.c # uclibc toolchain
cp a.out $CHROOT
In chroot:
bash-3.00$ valgrind /a.out
==16527== Memcheck, a memory error detector.
==16527== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==16527== Using LibVEX rev 1418, a library for dynamic binary translation.
==16527== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==16527== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework.
==16527== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==16527== For more details, rerun with: -v
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x40029EF: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x40022B7: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x4002306: _dl_load_shared_library (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x4002E5F: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x40025EA: _dl_fixup (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x400261F: _dl_fixup (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x400266E: _dl_fixup (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40031F9: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== Conditional jump or move depends on uninitialised value(s)
==16527== at 0x40032AC: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so)
==16527== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so)
==16527==
==16527== ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0)
==16527== malloc/free: in use at exit: 0 bytes in 0 blocks.
==16527== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==16527== For counts of detected errors, rerun with: -v
==16527== No malloc'd blocks -- no leaks are possible.
bash-3.00$ ldd /a.out
ldd: can't open cache '/etc/ld.so.cache'
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40007000)
libc.so.0 => /lib/libc.so.0 (0x4000f000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
It's not statically linked.
Any ideas what's wrong? When running the same program against
the same svn-version of valgrind on my regular system i get
this:
frank@linux:~> valgrind a.out
==16442== Memcheck, a memory error detector.
==16442== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==16442== Using LibVEX rev 1418, a library for dynamic binary translation.
==16442== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==16442== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework.
==16442== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==16442== For more details, rerun with: -v
==16442==
==16442==
==16442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==16442== malloc/free: in use at exit: 100 bytes in 10 blocks.
==16442== malloc/free: 10 allocs, 0 frees, 100 bytes allocated.
==16442== For counts of detected errors, rerun with: -v
==16442== searching for pointers to 10 not-freed blocks.
==16442== checked 65,620 bytes.
==16442==
==16442== LEAK SUMMARY:
==16442== definitely lost: 100 bytes in 10 blocks.
==16442== possibly lost: 0 bytes in 0 blocks.
==16442== still reachable: 0 bytes in 0 blocks.
==16442== suppressed: 0 bytes in 0 blocks.
==16442== Use --leak-check=full to see details of leaked memory.
TIA Frank
|
|
From: Tom H. <to...@co...> - 2005-10-11 10:55:20
|
In message <216...@ma...>
Santosh Itkare <san...@gm...> wrote:
> I got as follows
>
> --17896-- REDIR: 0x1BB05B20 (memset) redirected to 0x1B900B54 (memset)
> --17896-- REDIR: 0x1BB04500 (rindex) redirected to 0x1B900224 (rindex)
> --17896-- REDIR: 0x1BB041D0 (strlen) redirected to 0x1B9004D4 (strlen)
> --17896-- REDIR: 0x1BB043B0 (strncmp) redirected to 0x1B9006E0 (strncmp)
> --17896-- REDIR: 0x1BB04470 (strncpy) redirected to 0x1B9005D8 (strncpy)
> --17896-- REDIR: 0x1BB02E30 (index) redirected to 0x1B9002CC (index)
> --17896-- REDIR: 0x1BB03A40 (strcpy) redirected to 0x1B900528 (strcpy)
> --17896-- REDIR: 0x1BB02FA0 (strcmp) redirected to 0x1B900738 (strcmp)
> --17896-- REDIR: 0x1BB06130 (memcpy) redirected to 0x1B9007BC (memcpy)
Those don't tell you much it is the "redir resolved" lines that are
important.
> in my program I have used calloc and malloc then also it won't
> redirect them to ur program. so can you tell me what is wrong and
> how can I check my memeory-leaks more easily.
Is your program statically linked? If it is then valgrind can't
intercept the calls and you will need to dynamically link it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Santosh I. <san...@gm...> - 2005-10-11 10:28:29
|
---------- Forwarded message ---------- From: Santosh Itkare <san...@gm...> Date: Oct 11, 2005 3:24 PM Subject: To: val...@va... Hi, I am tring your memcheck tool for memory-leak checking but in this it won't redirect malloc and calloc function to your malloc and calloc function. Hence I am getting result as No malloc'd blocks -- no leaks are possible. so can you plz tell me what is wrong. what I have tried is: #valgrind --tool=3Dmemcheck --leak-check=3Dfull --leak-resolution=3Dlow --show-reachable=3Dyes -v ./webs -d -f ../../ where webs is my program(to be running and check) I got as follows --17896-- REDIR: 0x1BB05B20 (memset) redirected to 0x1B900B54 (memset) --17896-- REDIR: 0x1BB04500 (rindex) redirected to 0x1B900224 (rindex) --17896-- REDIR: 0x1BB041D0 (strlen) redirected to 0x1B9004D4 (strlen) --17896-- REDIR: 0x1BB043B0 (strncmp) redirected to 0x1B9006E0 (strncmp) --17896-- REDIR: 0x1BB04470 (strncpy) redirected to 0x1B9005D8 (strncpy) --17896-- REDIR: 0x1BB02E30 (index) redirected to 0x1B9002CC (index) --17896-- REDIR: 0x1BB03A40 (strcpy) redirected to 0x1B900528 (strcpy) --17896-- REDIR: 0x1BB02FA0 (strcmp) redirected to 0x1B900738 (strcmp) --17896-- REDIR: 0x1BB06130 (memcpy) redirected to 0x1B9007BC (memcpy) in my program I have used calloc and malloc then also it won't redirect the= m to ur program. so can you tell me what is wrong and how can I check my memeory-leaks more easily. -- Have A Good Day Good Bye Santosh -- Have A Good Day Good Bye Santosh |