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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(1) |
2
(5) |
3
(2) |
|
4
(5) |
5
(2) |
6
(2) |
7
|
8
(3) |
9
(6) |
10
(1) |
|
11
(3) |
12
|
13
(2) |
14
(7) |
15
(8) |
16
(8) |
17
(3) |
|
18
(7) |
19
|
20
(12) |
21
(9) |
22
(6) |
23
(13) |
24
|
|
25
|
26
(5) |
27
(6) |
28
(4) |
|
|
|
|
From: Julian S. <js...@ac...> - 2007-02-15 19:18:57
|
> Do you have any explanation for this ? I presume you really mean Valgrind's Memcheck tool. Our policy is to make Memcheck have zero false errors, and generally we are successful with this. If you are getting a lot of errors you do not expect, this may be a bug in Memcheck. I suggest you first try 3.2.3 - this has some fixes that are not in 3.2.1 - and if you still have unexpected errors then you will need to send some details so we can figure out what the problem is. J |
|
From: <Mar...@pr...> - 2007-02-15 16:14:28
|
Hello, we were using valgrind as one of the most valuable tools when it comes to=20 debug "mean" errors of our Qt 3.3.2 application. With valgrind 2.4.0 there = was some reasonable amount of noise and it found many errors for us. But with valgrind 3.2.1 (most possibly earlier versions, too) we get so=20 many qt errors that we can't use it. I tried to create a large suppression = file with=20 valgrind --gen-suppressions=3Dall --log-fd=3D4 program.bin 4> supp.tmp egrep "^[^=3D-]" supp.tmp > supp and abort()ed my program just before I suspected an error. Then I started=20 valgrind like this: valgrind --suppressions=3Dsupp program.bin=20 But as soon as the program got past the previously abort()ed section,=20 valgrind again reported loads and loads of errors. So version 3.2.1 seems=20 unusable to us... Do you have any explanation for this ? Has valgrind become so exact or so=20 advanced that it detects so much more errors ? Should we just stick to=20 version 2.4.0 or does it have serious disatvantages ?=20 Many thanks for your help, Markus Grunwald Softwaredevelopment PR=DCFTECHNIK Condition Monitoring GmbH Oskar-Messter-Stra=DFe 19-21 85737 Ismaning www.pruftechnik.com Tel: +49 (0)89 99616177 Fax: +49 (0)89 99616200 |
|
From: Josef W. <Jos...@gm...> - 2007-02-15 14:33:31
|
On Thursday 15 February 2007, Oliver Dawid wrote: > ---snip--- > ... > ==874== Invalid read of size 4 > ==874== at 0x10009D38: ??? > ==874== by 0x10008EC0: ??? > ==874== by 0x10005C44: ??? > ==874== by 0x10008108: ??? > ==874== by 0x100087E4: ??? > ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) > ==874== Address 0x402DFAC is 12 bytes inside a block of size 32 free'd > ==874== at 0xFFBBEC4: operator delete(void*) (in /opt/nfs/usr/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) > ==874== by 0x10005BAC: ??? > ==874== by 0x100080B8: ??? > ==874== by 0x100087E4: ??? > ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) > ==874== > ... > ---snip--- > > The maps file contains this: > ---snip--- > ... > 10000000-10014000 rwxp 00000000 00:09 2839186 /opt/nfs/usr/bin/mmscript > 10023000-10026000 rwxp 00013000 00:09 2839186 /opt/nfs/usr/bin/mmscript OK, that definitly seems to be a shortcoming in symbol reading in valgrind. Can you please raise a bug report with above information to not forget about this issue? Thanks, Josef |
|
From: Oliver D. <od...@pa...> - 2007-02-15 08:42:11
|
Hi, Josef Weidendorfer wrote: > Actually, no idea about that. For sure, if the addresses are inside of > a mapping of your application code (or a shared library), VG should know > about it. Can you check whether /proc/<pid>/maps for the mappings used for > these addresses, while VG is running your code? > If they are inside of anonymous memory ranges, VG can not be able to name > them. This would be the case with code generated on the fly. I ran my program an saved maps file. Here are the results: valgrind --tool=memcheck produced the following: ---snip--- ... ==874== Invalid read of size 4 ==874== at 0x10009D38: ??? ==874== by 0x10008EC0: ??? ==874== by 0x10005C44: ??? ==874== by 0x10008108: ??? ==874== by 0x100087E4: ??? ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) ==874== Address 0x402DFAC is 12 bytes inside a block of size 32 free'd ==874== at 0xFFBBEC4: operator delete(void*) (in /opt/nfs/usr/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) ==874== by 0x10005BAC: ??? ==874== by 0x100080B8: ??? ==874== by 0x100087E4: ??? ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) ==874== ... ---snip--- The maps file contains this: ---snip--- ... 10000000-10014000 rwxp 00000000 00:09 2839186 /opt/nfs/usr/bin/mmscript 10023000-10026000 rwxp 00013000 00:09 2839186 /opt/nfs/usr/bin/mmscript ... ---snip--- Obviously the addresses from valgrinds output are located in my binary which contains symbols. From objdump -t --demangle I get e.g.: ---snip--- ... 10007dec g F .text 0000044c parseInput(std::basic_istream<char, std::char_traints<char> >&) ... ---snip--- Which is the function where this error above occurs. 0x100080B8 is inside the function above (parseInput). 0x100087E4 is inside main: ---snip--- ... 10008518 g F .text 0000037c main ... ---snip--- I did not look into valgrind code (and I doubt it makes any sense) but there seems to be a problem in symbol lookup part. Oliver PS: I did also a callgrind run and found corresponding entries in output file: cfn=(5070) 0x10007DEC cfn=(4810) 0x1000852C cfn=(6328) 0x10005BDC cfn=(6336) 0x10008E70 and so on. |
|
From: Olly B. <ol...@su...> - 2007-02-15 04:28:54
|
On 2007-02-15, <rag...@wi...> wrote: > I need to find out memory leak or any such bugs in my code written > for a switch(Layer-2 operated network switches). Its mips architecture, > which uses linux. Valgrind doesn't support MIPS: http://valgrind.org/info/platforms.html Perhaps you can compile the code for a supported processor and run it under valgrind on a machine with that architecture, though I suspect that would be a struggle if it's written for an embedded application and expecting particular hardware... Cheers, Olly |
|
From: <rag...@wi...> - 2007-02-15 03:43:26
|
Hi All,
=20
I need to find out memory leak or any such bugs in my code written
for a switch(Layer-2 operated network switches). Its mips architecture,
which uses linux. My doubts are as below.
=20
1. can i cross compile and use the tool directly on the switch shell as
we do in linux machine. I mean in order to know memory leak in some
a.out I use following command in linux.=20
=20
valgrind --tool=3Dmemcheck --time-stamp=3Dyes --leak-check=3Dfull =
./a.out
=20
Since on switch my code runs as a thread, can any one tell me how to
I run valgrind for a thread?
=20
2. Is there any such tool available of eCos?
=20
Thanx in Advance.
=20
---Raghu.
=20
|
|
From: Josef W. <Jos...@gm...> - 2007-02-14 18:57:40
|
On Wednesday 14 February 2007, Oliver Dawid wrote: > But this wasn't the problem I have. I get tons of addresses instead of > symbols as I expected: > > cfn=(7880) 0x00045EFC > cfn=(3574) 0x000194D8 > cfn=(3584) 0x000195FC > cfn=(3754) 0x000419A0 > cfn=(3914) 0x0002C2C4 > cfn=(4002) 0x00022280 > cfn=(7662) 0x0001CC70 > cfn=(7802) 0x0002A4F4 > cfn=(7868) 0x00040A80 > cfn=(7936) 0x0004B7F8 > > While reference numbers are not comparable to my i686 output, I can only > guess, that these symbols belong to code from my main > binary. When I load that callgrind.out file into Kcachegrind I get binary > object: unknown. Actually, no idea about that. For sure, if the addresses are inside of a mapping of your application code (or a shared library), VG should know about it. Can you check whether /proc/<pid>/maps for the mappings used for these addresses, while VG is running your code? If they are inside of anonymous memory ranges, VG can not be able to name them. This would be the case with code generated on the fly. > Other methods/ functions from libc or ld > are displayed with their symbol names (although there are functions, which also only have an address like above). > > I tried several debugging and profiling options for the gcc without change. > > When I use nm or objdump, I can see these symbols, so my binary definitely > contains debug symbols. Ah. You know which functions _should_ be called, and get the addresses above instead? Perhaps this is some trampoline code generated on the fly which calls the real functions instead? I ask because if KCachegrind talks about "unknown object", the addresses actually are absolute. So I do not see how you could search for these addresses in any binary, as you do not know the offset where it is mapped at run time. However, when callgrind knows about the binary, the address is a relative offset into the code segment, which can be used with nm/objdump. > This seems to be a more common problem not only for callgrind. When running a memcheck I get stacks looking like this: > > ==917== Invalid read of size 4 > ==917== at 0x10005C04: ??? > ==917== by 0x100080E0: ??? > ==917== by 0x1000854C: ??? > ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) > ==917== Address 0x4026F44 is 4 bytes inside a block of size 32 free'd > ==917== at 0xFFBBEC4: operator delete(void*) (vg_replace_malloc.c:244) > ==917== by 0x10005B84: ??? > ==917== by 0x10008090: ??? > ==917== by 0x1000854C: ??? > ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) Interesting. However, the addresses here are totally different from the ones above. > Any idea? Sorry, not really. Josef PS: You should know that call graph generation currently is kind of experimental with PPC. |
|
From: Christoph B. <bar...@or...> - 2007-02-14 16:23:48
|
Am Mittwoch, 14. Februar 2007 schrieb amir flax: > hello all > > can i run valgrind as a non root user? > if yes, how? Yes. The same way as you would do it as root. Try: valgrind --num-callers=32 --time-stamp=yes /bin/ls Christoph |
|
From: Oliver D. <od...@pa...> - 2007-02-14 16:18:04
|
(repost - did not send posting to the list) Hi Josef, Josef Weidendorfer wrote: > On Tuesday 13 February 2007, Oliver Dawid wrote: >> Hi, >> >> I am trying to use callgrind to improve C++ software which is cross compiled for a ppc platform. When running valgrind >> --tool=callgrind on my testplatform, all symbols from the main file are missing so I only get addresses. On my host system >> everything is fine I find my methods in the output. >> >> ppc: >> fn=(5930) >> >> i686: >> fn=(5930) Request::Request(std::string const&, std::string const&, >> std::string const&, std::istream&) > > This "(5930)" has nothing to do with any address, but is part of a > compression scheme for callgrind.out files. It references the symbol > no. 5930; at first occurence, this includes the symbol name, on > further occurences the symbol name is left out. Ok. > So: > > (1) Symbol 9530 can reference different symbols at every invocation > of callgrind, even with the same program, but more so on different > architectures; however, this is a pure file-internal mapping to > get shorter files (especially for C++); you can switch it off > with "--compress-strings=no". > > (2) The missing symbol name next to (5930) only means that the > mapping of the number to the name already appeared earlier in the > file, perhaps in a line "cfn=(5930) random_symbol". Can you do > a "grep \(5930\) callgrind.out" to check this? If there in fact > is no line which installs a symbol mapping for 5930, this would be > a bug in writing the output, but does not mean anything regarding > to missing debug info. Ok, got that. Here is the output. It was defined earlier in the file: cfn=(5930) boost::detail::shared_count::shared_count<char*, boost::checked_array_deleter<char> >(char*, boost::checked_array_deleter<char>) fn=(5930) But this wasn't the problem I have. I get tons of addresses instead of symbols as I expected: cfn=(7880) 0x00045EFC cfn=(3574) 0x000194D8 cfn=(3584) 0x000195FC cfn=(3754) 0x000419A0 cfn=(3914) 0x0002C2C4 cfn=(4002) 0x00022280 cfn=(7662) 0x0001CC70 cfn=(7802) 0x0002A4F4 cfn=(7868) 0x00040A80 cfn=(7936) 0x0004B7F8 While reference numbers are not comparable to my i686 output, I can only guess, that these symbols belong to code from my main binary. When I load that callgrind.out file into Kcachegrind I get binary object: unknown. Other methods/ functions from libc or ld are displayed with their symbol names (although there are functions, which also only have an address like above). I tried several debugging and profiling options for the gcc without change. When I use nm or objdump, I can see these symbols, so my binary definitely contains debug symbols. This seems to be a more common problem not only for callgrind. When running a memcheck I get stacks looking like this: ==917== Invalid read of size 4 ==917== at 0x10005C04: ??? ==917== by 0x100080E0: ??? ==917== by 0x1000854C: ??? ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) ==917== Address 0x4026F44 is 4 bytes inside a block of size 32 free'd ==917== at 0xFFBBEC4: operator delete(void*) (vg_replace_malloc.c:244) ==917== by 0x10005B84: ??? ==917== by 0x10008090: ??? ==917== by 0x1000854C: ??? ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) Any idea? |
|
From: amir f. <flo...@gm...> - 2007-02-14 16:07:23
|
hello all can i run valgrind as a non root user? if yes, how? thanks |
|
From: Ashley P. <as...@qu...> - 2007-02-14 16:02:02
|
Hello,
This patch fixes up a oversight in the xml code, if the program dies
with a fatal signal the error message displayed isn't wrapped in xml
tags so it's impossible for external tools to load this information.
This patch puts <error></error> tags around it similar to how other
errors are displayed.
Currently:
Process terminating with default action of signal 11 (SIGSEGV): dumping core
Access not within mapped region at address 0x2
<stack>
<frame>
<ip>0x8048332</ip>
<obj>/tmp/a.out</obj>
<fn>main</fn>
</frame>
</stack>
With patch:
<error>
<tid>1</tid>
<kind>Signal</kind>
<signal>11</signal>
<what>Process terminating with default action of signal 11 (SIGSEGV): dumping core</what>
<event>Access not within mapped region</event>
<address>0x2</address>
<stack>
<frame>
<ip>0x8048332</ip>
<obj>/tmp/a.out</obj>
<fn>main</fn>
</frame>
</stack>
</error>
Ashley,
$ svn diff coregrind/m_signals.c
Index: coregrind/m_signals.c
===================================================================
--- coregrind/m_signals.c (revision 6536)
+++ coregrind/m_signals.c (working copy)
@@ -1206,11 +1206,21 @@
}
if (VG_(clo_verbosity) > 1 || (could_core && info->si_code > VKI_SI_USER)) {
- VG_(message)(Vg_UserMsg, "");
- VG_(message)(Vg_UserMsg,
- "Process terminating with default action of signal %d (%s)%s",
- sigNo, signame(sigNo), core ? ": dumping core" : "");
-
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, "<error>");
+ VG_(message)(Vg_UserMsg, " <tid>%d</tid>", tid);
+ VG_(message)(Vg_UserMsg, " <kind>Signal</kind>");
+ VG_(message)(Vg_UserMsg, " <signal>%d</signal>",sigNo);
+ VG_(message)(Vg_UserMsg,
+ " <what>Process terminating with default action of signal %d (%s)%s</what>",
+ sigNo, signame(sigNo), core ? ": dumping core" : "");
+ } else {
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg,
+ "Process terminating with default action of signal %d (%s)%s",
+ sigNo, signame(sigNo), core ? ": dumping core" : "");
+ }
+
/* Be helpful - decode some more details about this fault */
if (info->si_code > VKI_SI_USER) {
const Char *event = NULL;
@@ -1276,17 +1286,27 @@
}
if (event != NULL) {
- if (haveaddr)
- VG_(message)(Vg_UserMsg, " %s at address %p",
- event, info->VKI_SIGINFO_si_addr);
- else
- VG_(message)(Vg_UserMsg, " %s", event);
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, " <event>%s</event>", event);
+ if (haveaddr)
+ VG_(message)(Vg_UserMsg, " <address>%p</address>",
+ info->VKI_SIGINFO_si_addr);
+ } else {
+ if (haveaddr)
+ VG_(message)(Vg_UserMsg, " %s at address %p",
+ event, info->VKI_SIGINFO_si_addr);
+ else
+ VG_(message)(Vg_UserMsg, " %s", event);
+ }
}
}
if (tid != VG_INVALID_THREADID) {
VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
}
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, "</error>");
+ }
}
if (VG_(is_action_requested)( "Attach to debugger", & VG_(clo_db_attach) )) {
|
|
From: Igmar P. <mai...@jd...> - 2007-02-14 07:48:43
|
> Below seem to generate Pthread Memory leaks. How should one get rid of it? Convince the libc maintainers to accept patches to fix this. Igmar |
|
From: Mukesh K. S. <sr...@ya...> - 2007-02-14 06:51:28
|
Hi All. Below seem to generate Pthread Memory leaks. How should one get rid of it? ----- ==21324== 288 bytes in 2 blocks are possibly lost in loss record 7 of 10 ==21324== at 0x40045EB: calloc (vg_replace_malloc.c:279) ==21324== by 0x6124FA: _dl_allocate_tls (in /lib/ld-2.4.so) ==21324== by 0x9069E2: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.4.so) ==21324== by 0x8057F1B: ----- Do they get created at the start and deleted at the end and therefore memory doesn't leak away in an operational system. BR Mukesh --------------------------------- Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. |
|
From: Josef W. <Jos...@gm...> - 2007-02-13 15:46:16
|
On Tuesday 13 February 2007, Oliver Dawid wrote: > Hi, > > I am trying to use callgrind to improve C++ software which is cross compiled for a ppc platform. When running valgrind > --tool=callgrind on my testplatform, all symbols from the main file are missing so I only get addresses. On my host system > everything is fine I find my methods in the output. > > ppc: > fn=(5930) > > i686: > fn=(5930) Request::Request(std::string const&, std::string const&, > std::string const&, std::istream&) This "(5930)" has nothing to do with any address, but is part of a compression scheme for callgrind.out files. It references the symbol no. 5930; at first occurence, this includes the symbol name, on further occurences the symbol name is left out. So: (1) Symbol 9530 can reference different symbols at every invocation of callgrind, even with the same program, but more so on different architectures; however, this is a pure file-internal mapping to get shorter files (especially for C++); you can switch it off with "--compress-strings=no". (2) The missing symbol name next to (5930) only means that the mapping of the number to the name already appeared earlier in the file, perhaps in a line "cfn=(5930) random_symbol". Can you do a "grep \(5930\) callgrind.out" to check this? If there in fact is no line which installs a symbol mapping for 5930, this would be a bug in writing the output, but does not mean anything regarding to missing debug info. Josef > Seems like the ppc version cannot find the debug information. > > I am using valgrind version 3.2.3 and ppc_82xx-g++ version 3.2.2 (from eldk-3.0) for my targe platform and valgrind 3.2.3 and g++ > 4.0.4 on my host platform. > > Did I overlook something? Do I have to use gcc 4 for my target platform? > > Oliver > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Oliver D. <od...@pa...> - 2007-02-13 14:38:04
|
Hi, I am trying to use callgrind to improve C++ software which is cross compiled for a ppc platform. When running valgrind --tool=callgrind on my testplatform, all symbols from the main file are missing so I only get addresses. On my host system everything is fine I find my methods in the output. ppc: fn=(5930) i686: fn=(5930) Request::Request(std::string const&, std::string const&, std::string const&, std::istream&) Seems like the ppc version cannot find the debug information. I am using valgrind version 3.2.3 and ppc_82xx-g++ version 3.2.2 (from eldk-3.0) for my targe platform and valgrind 3.2.3 and g++ 4.0.4 on my host platform. Did I overlook something? Do I have to use gcc 4 for my target platform? Oliver |
|
From: Tom H. <to...@co...> - 2007-02-11 15:29:53
|
In message <465...@we...>
"Mukesh K. Srivastava" <sr...@ya...> wrote:
> I am looking to perform cross-compile for mx21[ARM] using Valgrind for which I have done following -
Good luck...
> checking for a supported version of gcc... ok (arm-linux-gcc (GCC) 3.3.2)
> checking build system type... arm-unknown-none
> checking host system type... arm-unknown-linux-gnu
> checking for a supported CPU... no (arm)
> configure: error: Unsupported host architecture. Sorry
As you have just discovered, there is not support for ARM as a target
in valgrind.
> Any clue to resolve error message "checking for a supported CPU... no (arm)".
Implementing ARM support in valgrind is the only way to resolve it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2007-02-11 14:27:08
|
Mukesh K. Srivastava wrote: > Any clue to resolve error message "checking for a supported CPU... no > (arm)". Clue: check whether the CPU is supported: http://valgrind.org/info/platforms.html Cheers, |
|
From: Mukesh K. S. <sr...@ya...> - 2007-02-11 14:23:18
|
Hi All. I am looking to perform cross-compile for mx21[ARM] using Valgrind for which I have done following - (a) uname -a Linux 2.6.16-1.2080_FC5 #1 Tue Mar 28 03:38:34 EST 2006 i686 i686 i386 GNU/Linux (b) Set the PATH for MX21 toolchain. (c) ./configure --prefix=/home/mukeshs/mx21 --exec-prefix=/home/mukeshs/mx21 --disable-tls --host=arm-linux --build=arm I get following error messages - --- checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for arm-linux-strip... arm-linux-strip checking whether to enable maintainer-specific portions of Makefiles... no checking whether ln -s works... yes checking for arm-linux-gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-linux-gcc accepts -g... yes checking for arm-linux-gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of arm-linux-gcc... gcc3 checking how to run the C preprocessor... arm-linux-gcc -E checking for arm-linux-g++... arm-linux-g++ checking whether we are using the GNU C++ compiler... yes checking whether arm-linux-g++ accepts -g... yes checking dependency style of arm-linux-g++... gcc3 checking for arm-linux-ranlib... arm-linux-ranlib checking for perl... /usr/bin/perl checking for gdb... /usr/bin/gdb checking for a supported version of gcc... ok (arm-linux-gcc (GCC) 3.3.2) checking build system type... arm-unknown-none checking host system type... arm-unknown-linux-gnu checking for a supported CPU... no (arm) configure: error: Unsupported host architecture. Sorry --- Any clue to resolve error message "checking for a supported CPU... no (arm)". BR Mukesh --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. |
|
From: Mathew Y. <my...@jp...> - 2007-02-10 00:03:06
|
Hi I'd love to use valgrind on Solaris/x86. Is there any kind of porting guide? I'm curious about how difficult the port would be. Thanks Mathew -- |
|
From: Josef W. <Jos...@gm...> - 2007-02-09 20:04:40
|
On Friday 09 February 2007, Olly Betts wrote: > On 2007-02-09, Josef Weidendorfer <Jos...@gm...> wrote: > > First, do not quote the function name. If there are characters which > > could be interpreted by the shell, either put a backslash before that > > character, or quote the whole argument. > > You can quote any subpart(s) of an argument to protect it from the > shell. So '--toggle-collect=sloop' and --toggle-collect='sloop' should > behave identically. For example, try: > > perl -e 'print "|$ARGV[0]|\n"' -- '--toggle-collect=sloop' > perl -e 'print "|$ARGV[0]|\n"' -- --toggle-collect='sloop' > > Both output: |--toggle-collect=sloop| Ah, thanks, I didn't know. I stand corrected. You never stop learning. Josef > > Cheers, > Olly > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Olly B. <ol...@su...> - 2007-02-09 19:32:04
|
On 2007-02-09, Josef Weidendorfer <Jos...@gm...> wrote:
> First, do not quote the function name. If there are characters which
> could be interpreted by the shell, either put a backslash before that
> character, or quote the whole argument.
You can quote any subpart(s) of an argument to protect it from the
shell. So '--toggle-collect=sloop' and --toggle-collect='sloop' should
behave identically. For example, try:
perl -e 'print "|$ARGV[0]|\n"' -- '--toggle-collect=sloop'
perl -e 'print "|$ARGV[0]|\n"' -- --toggle-collect='sloop'
Both output: |--toggle-collect=sloop|
Cheers,
Olly
|
|
From: Pierre-Antoine D.
|
Hello Josef, Your clear suggestions worked very well. Indeed, it would be good to update the doc... Anyway thank you very much for your help. Cheers, P.A. Josef Weidendorfer a =E9crit : > Hi, >=20 > On Friday 09 February 2007, Pierre-Antoine Delsart wrote: >> Dear valgrind users, >> >> I'm trying to profile a specific class function inside c++ code. >> As far as I understood the doc, this should be possible with the >> --toggle-collect switch. >> However I did not manage to use it with a class function. >> >> For example in the code below, would it be possible to start collectin= g=20 >> only on the AA::sloop() function ? >> >=20 > First, do not quote the function name. If there are characters which > could be interpreted by the shell, either put a backslash before that > character, or quote the whole argument. > You can not specify parts in the middle of a function name; it has > to be the full name or a prefix (see below). > Also note, that for C++, the function signature is part of the > symbol name. >=20 >> Trying --toggle-collect=3D'sloop' >=20 > This is not a prefix; can not work. >=20 >> or --toggle-collect=3D'AA:sloop' only =20 >> produced empty output. >=20 > Probably you wanted to say that you tested 'AA::sloop' > (2 colons instead of 1). >=20 > However, this is not the full symbol name. The full > name is "AA::sloop()", including the parenthesis. > But otherwise, and without the quotes, "AA::sloop" > _is_ a prefix and thus, it should work according to the > documentation. >=20 > Unfortunately, I just saw that the documentation > is outdated on this one. >=20 > You can specify limited globbing patterns, and have to use "*" at the > end when giving a function prefix. This was introduced already > some time ago in callgrind to be able to collect only in function > "func" even when there was e.g. a "func_a", too. The old (and > documented behavior) would not allow this. >=20 > In short: the following should be working (at least it does here): >=20 > valgrind --tool=3Dcallgrind "--toggle-collect=3DAA::sloop()" ./test >=20 > That's the full symbol. >=20 > valgrind --tool=3Dcallgrind --toggle-collect=3DAA::sloop* ./test >=20 > That's a symbol prefix specification. >=20 > It should be noted that you can specify multiple "--toggle-collect" > options to specify that you want to collect only inside of the function= s > specified. >=20 > I hope this helps for now. >=20 > I admit that it would be way better to have examples in the > documentation, and of course, not have outdated documentation in > the first place :-( >=20 > Josef |
|
From: Josef W. <Jos...@gm...> - 2007-02-09 19:14:12
|
Hi, On Friday 09 February 2007, Pierre-Antoine Delsart wrote: > Dear valgrind users, > > I'm trying to profile a specific class function inside c++ code. > As far as I understood the doc, this should be possible with the > --toggle-collect switch. > However I did not manage to use it with a class function. > > For example in the code below, would it be possible to start collecting > only on the AA::sloop() function ? > First, do not quote the function name. If there are characters which could be interpreted by the shell, either put a backslash before that character, or quote the whole argument. You can not specify parts in the middle of a function name; it has to be the full name or a prefix (see below). Also note, that for C++, the function signature is part of the symbol name. > Trying --toggle-collect='sloop' This is not a prefix; can not work. > or --toggle-collect='AA:sloop' only > produced empty output. Probably you wanted to say that you tested 'AA::sloop' (2 colons instead of 1). However, this is not the full symbol name. The full name is "AA::sloop()", including the parenthesis. But otherwise, and without the quotes, "AA::sloop" _is_ a prefix and thus, it should work according to the documentation. Unfortunately, I just saw that the documentation is outdated on this one. You can specify limited globbing patterns, and have to use "*" at the end when giving a function prefix. This was introduced already some time ago in callgrind to be able to collect only in function "func" even when there was e.g. a "func_a", too. The old (and documented behavior) would not allow this. In short: the following should be working (at least it does here): valgrind --tool=callgrind "--toggle-collect=AA::sloop()" ./test That's the full symbol. valgrind --tool=callgrind --toggle-collect=AA::sloop* ./test That's a symbol prefix specification. It should be noted that you can specify multiple "--toggle-collect" options to specify that you want to collect only inside of the functions specified. I hope this helps for now. I admit that it would be way better to have examples in the documentation, and of course, not have outdated documentation in the first place :-( Josef |
|
From: Pierre-Antoine D.
|
Dear valgrind users,
I'm trying to profile a specific class function inside c++ code.
As far as I understood the doc, this should be possible with the
--toggle-collect switch.
However I did not manage to use it with a class function.
For example in the code below, would it be possible to start collecting
only on the AA::sloop() function ?
Trying --toggle-collect='sloop' or --toggle-collect='AA:sloop' only
produced empty output.,,,
Thanks for any help.
P.A.D
My test code :
#include <iostream>
class AA {
public:
int a;
AA(){a=0;}
void sloop(){
a++;
for(int i=0;i<10000;i++) a+=45;
loop();
std::cout << " "<<a <<std::endl;
}
void loop();
};
void AA::loop(){
for(int i=0;i<10000;i++) a = a+ a /45;
}
and the main file :
#include "test.cxx"
int main(){
AA ca;
ca.sloop();
ca.sloop();
ca.sloop();
}
|
|
From: Jose C. <jos...@if...> - 2007-02-09 12:56:19
|
Hi everyone, I am using Valgrind 3.2.3, trying to compile it in a cross-compile environment, with following information: Host machine: PowerPC with Linux 2.4.25 Cross compiler: ppc-linux-gcc (GCC) 3.3.3 (DENX ELDK 3.1.1 3.3.3-10) Compiling in a i686 machine with Linux 2.4.21-138-smp To configure Valgrind, I used the following command: ./valgrind-3.2.3> ./configure --prefix=/data/valgrind --exec-prefix=/data/valgrind --disable-tls --host=ppc-linux --build=ppc (The folder /data/valgrind will be later mounted in the PowerPC machine over NFS) Then, I use "make install" to compile it: no error was reported, just a couple of warnings in sim.c and calling inline functions. I had to execute ./VEX/auxprogs/genoffsets after logging in the host PPC machine. My issue is the following: I launched valgrind and try to debug the "busybox" application, running the "date" command. It does not depend on the application (tried with lots of them) and I received always the follwing error: valgrind: /bin/busybox: bad ELF magic number I searched in google and anything was found. Then, I looked in to valgrind source code and I found that the problem is in the function VG_(pread). This function does not fill the information from the file into the buffer. I do not know if my problem root is in the Valgrind configuration and/or compilation, or in the Valgrind version, or ther cause. Ideas? Thanks for the help, Jose Camacho -- View this message in context: http://www.nabble.com/Error-%22Bad-ELF-magic-number%22-tf3200231.html#a8885223 Sent from the Valgrind - Users mailing list archive at Nabble.com. |