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
(2) |
2
(4) |
3
(3) |
4
(1) |
5
(3) |
|
6
(5) |
7
(16) |
8
(10) |
9
(2) |
10
(3) |
11
(1) |
12
(5) |
|
13
(5) |
14
(5) |
15
(8) |
16
(4) |
17
(3) |
18
(2) |
19
(1) |
|
20
(2) |
21
(4) |
22
(2) |
23
(9) |
24
(1) |
25
(5) |
26
|
|
27
|
28
(1) |
29
(3) |
30
(1) |
|
|
|
|
From: Ed S. <ES...@fe...> - 2010-06-07 18:22:51
|
On Jun 7, 2010, at 12:25 PM, John Reiser wrote: >> 1. ulimit -c unlimited ( I did not have core dump enabled ) >> 2. valgrind --leak-check=yes ./debugmemoryleak >> 3. gdb ./debugmemoryleak vgcore.6491 >> 4. (gdb) x/8x 0x9ceb615 >> 5. 0x9ceb615: 0xec8b55cb > > Assuming that we are looking in the same place as the CPU was: > Opcode 0xcb (the low-order byte in 0xec8b55cb) is 'lret' (RET far) > which expects a 48-bit segmented return address (which was pushed > onto the stack as two 32-bit words). Valgrind assumes that > code is written for a flat, non-segmented, addressing model; > all return addresses are 32-bits only [on a 32-bit machine.] > > So that library contains (or is generating) code that valgrind > won't understand. Ask the purveyor of the library about this. So as I understand it the 48-bit segmented addressing opcode is valid but Valgrind 3.5.0 does not recognize it and raises an exception. I assume it is not worth submitting a bug report, especially for my own personal benefit, as it may never be supported. > > If you are truly desperate, then get a wizard to patch the code > so that '0xcb' becomes '0xc2 0x04 0x00' (RET near $4). This > will discard the segment register information, and might work. Good suggestion and might be worth it if it helps me uncover any real memory leaks. Thank you for your and everyone's help, -Ed |
|
From: John R. <jr...@bi...> - 2010-06-07 17:26:07
|
> 1. ulimit -c unlimited ( I did not have core dump enabled ) > 2. valgrind --leak-check=yes ./debugmemoryleak > 3. gdb ./debugmemoryleak vgcore.6491 > 4. (gdb) x/8x 0x9ceb615 > 5. 0x9ceb615: 0xec8b55cb Assuming that we are looking in the same place as the CPU was: Opcode 0xcb (the low-order byte in 0xec8b55cb) is 'lret' (RET far) which expects a 48-bit segmented return address (which was pushed onto the stack as two 32-bit words). Valgrind assumes that code is written for a flat, non-segmented, addressing model; all return addresses are 32-bits only [on a 32-bit machine.] So that library contains (or is generating) code that valgrind won't understand. Ask the purveyor of the library about this. If you are truly desperate, then get a wizard to patch the code so that '0xcb' becomes '0xc2 0x04 0x00' (RET near $4). This will discard the segment register information, and might work. -- |
|
From: Ed S. <ES...@fe...> - 2010-06-07 17:04:12
|
It will help a lot if you specify the byte values (say, 8 of them) in the instruction stream at address 0x9ceb615. How would I do this? $ gdb valgrind (gdb) run arguments-to-valgrind my-app arguments-to-my-app [snip] ==1460== valgrind: Unrecognised instruction at address 0x9ceb615. [snip] ==1460== Process terminating with default action of signal 4 (SIGILL) ==1460== Illegal opcode at address 0x9CEB615 ==1460== at 0x9CEB615: ??? [snip] (gdb) x/4x 0x9ceb615 Thanks. I had trouble with the above. Hopefully the below is the equivalent using valgringd 3.5.0 : 1. ulimit -c unlimited ( I did not have core dump enabled ) 2. valgrind --leak-check=yes ./debugmemoryleak 3. gdb ./debugmemoryleak vgcore.6491 4. (gdb) x/8x 0x9ceb615 5. 0x9ceb615: 0xec8b55cb 0x8b515756 0x15e3104d 0x8b0c758b 6. 0x9ceb625: 0xc18b087d 0xfc02e9c1 0xc88ba5f3 0xf303e183 I suspect the decoder may contain AMD specific opcodes as well. What tool is used to determine if these are valid opcodes, perhaps not for Intel 32-bit but perhaps valid 64-bit or AMD 32/64? Or maybe just some random data that a bad jump arrived at? The app runs without core dumping when run without Valgrind. Memory usage is steady. The problem I see is that reported memory usage increase each time I destroy and create new objects which is why started to investigate with Valgrind. >The only important change in this case is whether it still crashes or not. Ok. I saw no change it stills raises signal when it encounters unrecognized opcodes so I guess the decoder is not generating code dynamically. -Ed -- ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users -Ed |
|
From: John R. <jr...@bi...> - 2010-06-07 16:22:58
|
>>> It will help a lot if you specify the byte values (say, 8 of them) >>> in the instruction stream at address 0x9ceb615. > How would I do this? $ gdb valgrind (gdb) run arguments-to-valgrind my-app arguments-to-my-app [snip] ==1460== valgrind: Unrecognised instruction at address 0x9ceb615. [snip] ==1460== Process terminating with default action of signal 4 (SIGILL) ==1460== Illegal opcode at address 0x9CEB615 ==1460== at 0x9CEB615: ??? [snip] (gdb) x/4x 0x9ceb615 -- |
|
From: Julian S. <js...@ac...> - 2010-06-07 16:20:03
|
> >> It will help a lot if you specify the byte values (say, 8 of them) > >> in the instruction stream at address 0x9ceb615. > > > > Yes. You didn't show the actual bytes it is complaining about, which > > are present in the failure message. Without those it is impossible to > > say anything. > > How would I do this? Look for a line in the crash report, like this (approximately) vex x86->IR: unhandled bytes: ... or vex amd64->IR: unhandled bytes: ... > I am trying this. I am still reading through the log file trying to see if > it changed anything. The only important change in this case is whether it still crashes or not. J |
|
From: Ed S. <ES...@fe...> - 2010-06-07 15:36:00
|
Thank you both for your assistance. > >> It will help a lot if you specify the byte values (say, 8 of them) >> in the instruction stream at address 0x9ceb615. > > Yes. You didn't show the actual bytes it is complaining about, which > are present in the failure message. Without those it is impossible to > say anything. How would I do this? I am new to Linux. The address 0x9ceb615 apparently is the address that the shared library is loaded. How would I get the opcode bytes? > >>> ==1460== by 0x726C4D: clone (in /lib/libc-2.5.so) >>> Red Hat Enterprise Linux 5.2 32-bit >> >> Remember to specify the version of valgrind when you file the bug report. >> The software that you did specify is somewhat old. The current version >> of valgrind is 3.5.0. I am using 3.5.0. > > Try also with --smc-check=all, just in the (unlikely but possible case) > that the library is generating code on the fly. I am trying this. I am still reading through the log file trying to see if it changed anything. Thanks for your help, -Ed |
|
From: Julian S. <js...@ac...> - 2010-06-07 15:14:25
|
> It will help a lot if you specify the byte values (say, 8 of them) > in the instruction stream at address 0x9ceb615. Yes. You didn't show the actual bytes it is complaining about, which are present in the failure message. Without those it is impossible to say anything. > > ==1460== by 0x726C4D: clone (in /lib/libc-2.5.so) > > Red Hat Enterprise Linux 5.2 32-bit > > Remember to specify the version of valgrind when you file the bug report. > The software that you did specify is somewhat old. The current version > of valgrind is 3.5.0. Try also with --smc-check=all, just in the (unlikely but possible case) that the library is generating code on the fly. J |
|
From: John R. <jr...@bi...> - 2010-06-07 14:44:59
|
> Question: Is there a way to Valgrind to stay out of a shared library? No. Any instruction which accesses data memory must be examined. > ==1460== valgrind: Unrecognised instruction at address 0x9ceb615. http://valgrind.org/docs/manual/faq.html#faq.msgdeath It will help a lot if you specify the byte values (say, 8 of them) in the instruction stream at address 0x9ceb615. > ==1460== by 0x726C4D: clone (in /lib/libc-2.5.so) > Red Hat Enterprise Linux 5.2 32-bit Remember to specify the version of valgrind when you file the bug report. The software that you did specify is somewhat old. The current version of valgrind is 3.5.0. -- |
|
From: Robert B. <gm...@re...> - 2010-06-07 14:42:36
|
Hi all, Just let me know when you have something for me to test. Regards, Robert -- Robert Berger Embedded Software Specialist Reliable Embedded Systems Consulting Training Engineering Tel.: (+30) 697 593 3428 Fax.:(+30) 210 684 7881 URL: http://www.reliableembeddedsystems.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ..."Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth, in a memo to Peter Van Emde Boas titled "Notes on the van Emde Boas construction of priority deques: An instructive use of recursion" My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 |
|
From: Ed S. <ES...@fe...> - 2010-06-07 13:27:04
|
Valgrind kills my process because of an unrecognized instruction. I suspect the commercial Pegasus image decoder I am using contains opcodes that may be valid for other architectures such as AMD but not the Intel architecture I am currently running on. Or perhaps they have some encoded opcodes for IP protection issues that they somehow extract at run-time. I really do not know. Question: Is there a way to Valgrind to stay out of a shared library? ==1460== valgrind: Unrecognised instruction at address 0x9ceb615. ==1460== Your program just tried to execute an instruction that Valgrind ==1460== did not recognise. There are two possible reasons for this. ==1460== 1. Your program has a bug and erroneously jumped to a non-code ==1460== location. If you are running Memcheck and you just saw a ==1460== warning about a bad jump, it's probably your program's fault. ==1460== 2. The instruction is legitimate but Valgrind doesn't handle it, ==1460== i.e. it's Valgrind's fault. If you think this is the case or ==1460== you are not sure, please let us know and we'll try to fix it. ==1460== Either way, Valgrind will now raise a SIGILL signal which will ==1460== probably kill your program. ==1460== Process terminating with default action of signal 4 (SIGILL) ==1460== Illegal opcode at address 0x9CEB615 ==1460== at 0x9CEB615: ??? ==1460== by 0x408755A: picosCallPegasusProc (in /usr/lib/fesvideo/libpicl20.so) ==1460== by 0x408185C: ??? (in /usr/lib/fesvideo/libpicl20.so) ==1460== by 0x4081A56: ??? (in /usr/lib/fesvideo/libpicl20.so) ==1460== by 0x4086AF1: threadfn (in /usr/lib/fesvideo/libpicl20.so) ==1460== by 0x7CF45A: start_thread (in /lib/libpthread-2.5.so) ==1460== by 0x726C4D: clone (in /lib/libc-2.5.so) I am trying to debug a memory leak under Red Hat Enterprise Linux 5.2 32-bit in an application that uses a 3rd part commercial image decoder made by Pegasus. Thanks in advance for any tips or direction, -Ed |
|
From: Tom H. <to...@co...> - 2010-06-07 07:48:17
|
On 07/06/10 07:15, Julian Seward wrote: >> Probably best just to use Math::BigInt then you can do arbitrary >> precision integer arithmetic regardless of the underlying platform. > > Is Math::BigInt is supported as standard in Perl? and also, in older > Perls? Obviously if the build process is going to rely on it then > it needs to be available on all perls we could reasonably expect to > encounter. Since at least 5.005 yes, and if you've got a system with anything older than that then you already have serious pain as that was released in July 1998. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2010-06-07 06:23:19
|
> Why Perl ? Perl isn't used anywhere yet during the Valgrind build -- > that would introduce an additional dependency. It just seems convenient, plus it is already a dependency and is checked for by the configure script. Some of the analysis scripts for Cachegrind and Massif are written in Perl (cg_annotate, ms_print), and maybe some others. > Bash can do 64-bit arithmetic as well. An example: > > $ bash -c 'echo $((1<<62))' > 4611686018427387904 Hmm, true. What about dash though? J |
|
From: Bart V. A. <bva...@ac...> - 2010-06-07 06:06:47
|
On Sun, Jun 6, 2010 at 10:41 PM, Julian Seward <js...@ac...> wrote: > Oh, darn. It looks like I broke cross compilation recently by > introducing link_tool_exe.c as part of the build process. > > Honestly .. the your best bet is to rewrite link_tool_exe.c as > a perl script, so it can run on the host. I actually started out > to write it as a perl script, but couldn't find a way to make it > portably do 64-bit arithmetic, which it needs to do on some platforms. > Hence I wimped out and wrote a C program instead. However, that > evidently isn't going to work in this case. Why Perl ? Perl isn't used anywhere yet during the Valgrind build -- that would introduce an additional dependency. Bash can do 64-bit arithmetic as well. An example: $ bash -c 'echo $((1<<62))' 4611686018427387904 Bart. |
|
From: Julian S. <js...@ac...> - 2010-06-07 05:53:33
|
> Probably best just to use Math::BigInt then you can do arbitrary > precision integer arithmetic regardless of the underlying platform. Is Math::BigInt is supported as standard in Perl? and also, in older Perls? Obviously if the build process is going to rely on it then it needs to be available on all perls we could reasonably expect to encounter. J |
|
From: Tom H. <to...@co...> - 2010-06-06 23:42:16
|
On 06/06/10 21:41, Julian Seward wrote: > Honestly .. the your best bet is to rewrite link_tool_exe.c as > a perl script, so it can run on the host. I actually started out > to write it as a perl script, but couldn't find a way to make it > portably do 64-bit arithmetic, which it needs to do on some platforms. > Hence I wimped out and wrote a C program instead. However, that > evidently isn't going to work in this case. Probably best just to use Math::BigInt then you can do arbitrary precision integer arithmetic regardless of the underlying platform. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Josef W. <Jos...@gm...> - 2010-06-06 20:33:02
|
On Friday 04 June 2010, R. P. Janaka wrote: > As mentioned in the manual, I was able to avoid this by using the* ** > --separate-recs=10* . > But I am still wondering why we get cycle for new or malloc (because they > should never call recursively ) Probably not a direct cycle, but a false one. It could be (just guessing): - malloc needs the runtime linker on first call - the runtime linker sometimes needs malloc Anyway, by traversing direct callees residing in the cycle function, you should be able to find a cyclic call chain yourself. Josef |
|
From: Julian S. <js...@ac...> - 2010-06-06 20:19:09
|
Oh, darn. It looks like I broke cross compilation recently by introducing link_tool_exe.c as part of the build process. Honestly .. the your best bet is to rewrite link_tool_exe.c as a perl script, so it can run on the host. I actually started out to write it as a perl script, but couldn't find a way to make it portably do 64-bit arithmetic, which it needs to do on some platforms. Hence I wimped out and wrote a C program instead. However, that evidently isn't going to work in this case. J On Sunday 06 June 2010, Robert Berger wrote: > Hi, > > I'm trying to get valgrind running with an AMCC PPC kilauea board, > ELDK4.2, and a recent kernel. > > That's what I did so far: > svn co svn://svn.valgrind.org/valgrind/trunk valgrind > cp dispatch-ppc32-linux.S valgrind/coregrind/m_dispatch > (that's a patched version, which gets rid of the altivec instructions) > cd valgrind > source ../../../env.sh > (this sets up my cross environment) > ./autogen.sh > ./configure --host=powerpc-linux > --prefix=$ELDK_PREFIX/eldk-4.2-ppc_4xx/ppc_4xx > make > > it fails like this: > mv -f .deps/memcheck_ppc32_linux-mc_translate.Tpo > .deps/memcheck_ppc32_linux-mc_translate.Po > powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include > -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 > -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith > -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length > -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign > -fno-stack-protector -MT memcheck_ppc32_linux-mc_machine.o -MD -MP -MF > .deps/memcheck_ppc32_linux-mc_machine.Tpo -c -o > memcheck_ppc32_linux-mc_machine.o `test -f 'mc_machine.c' || echo > './'`mc_machine.c > mv -f .deps/memcheck_ppc32_linux-mc_machine.Tpo > .deps/memcheck_ppc32_linux-mc_machine.Po > powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include > -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 > -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith > -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length > -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign > -fno-stack-protector -MT memcheck_ppc32_linux-mc_errors.o -MD -MP -MF > .deps/memcheck_ppc32_linux-mc_errors.Tpo -c -o > memcheck_ppc32_linux-mc_errors.o `test -f 'mc_errors.c' || echo > './'`mc_errors.c > mv -f .deps/memcheck_ppc32_linux-mc_errors.Tpo > .deps/memcheck_ppc32_linux-mc_errors.Po > ../coregrind/link_tool_exe 0x38000000 powerpc-linux-gcc -Wno-long-long > -Wno-pointer-sign -fno-stack-protector -o memcheck-ppc32-linux -m32 > -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith > -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length > -fno-strict-aliasing -O2 -static -nodefaultlibs -nostartfiles -u _start > -m32 memcheck_ppc32_linux-mc_leakcheck.o > memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o > memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o > memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a > ../VEX/libvex-ppc32-linux.a -lgcc > ../coregrind/link_tool_exe: ../coregrind/link_tool_exe: cannot execute > binary file > make[3]: *** [memcheck-ppc32-linux] Error 126 > make[3]: Leaving directory > `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind' > make: *** [all] Error 2 > > The link_tool_exe is a ppc executable, so it can not be executed by my > x86 host. > When I try not to build on my host but directly on my target it fails > because it does not find the aclocal. > > Please advise. > > Regards, > > Robert |
|
From: Robert B. <gm...@re...> - 2010-06-06 15:40:18
|
Hi, I'm trying to get valgrind running with an AMCC PPC kilauea board, ELDK4.2, and a recent kernel. That's what I did so far: svn co svn://svn.valgrind.org/valgrind/trunk valgrind cp dispatch-ppc32-linux.S valgrind/coregrind/m_dispatch (that's a patched version, which gets rid of the altivec instructions) cd valgrind source ../../../env.sh (this sets up my cross environment) ./autogen.sh ./configure --host=powerpc-linux --prefix=$ELDK_PREFIX/eldk-4.2-ppc_4xx/ppc_4xx make it fails like this: mv -f .deps/memcheck_ppc32_linux-mc_translate.Tpo .deps/memcheck_ppc32_linux-mc_translate.Po powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT memcheck_ppc32_linux-mc_machine.o -MD -MP -MF .deps/memcheck_ppc32_linux-mc_machine.Tpo -c -o memcheck_ppc32_linux-mc_machine.o `test -f 'mc_machine.c' || echo './'`mc_machine.c mv -f .deps/memcheck_ppc32_linux-mc_machine.Tpo .deps/memcheck_ppc32_linux-mc_machine.Po powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT memcheck_ppc32_linux-mc_errors.o -MD -MP -MF .deps/memcheck_ppc32_linux-mc_errors.Tpo -c -o memcheck_ppc32_linux-mc_errors.o `test -f 'mc_errors.c' || echo './'`mc_errors.c mv -f .deps/memcheck_ppc32_linux-mc_errors.Tpo .deps/memcheck_ppc32_linux-mc_errors.Po ../coregrind/link_tool_exe 0x38000000 powerpc-linux-gcc -Wno-long-long -Wno-pointer-sign -fno-stack-protector -o memcheck-ppc32-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -O2 -static -nodefaultlibs -nostartfiles -u _start -m32 memcheck_ppc32_linux-mc_leakcheck.o memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a ../VEX/libvex-ppc32-linux.a -lgcc ../coregrind/link_tool_exe: ../coregrind/link_tool_exe: cannot execute binary file make[3]: *** [memcheck-ppc32-linux] Error 126 make[3]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind' make: *** [all] Error 2 The link_tool_exe is a ppc executable, so it can not be executed by my x86 host. When I try not to build on my host but directly on my target it fails because it does not find the aclocal. Please advise. Regards, Robert -- Robert Berger Embedded Software Specialist Reliable Embedded Systems Consulting Training Engineering Tel.: (+30) 697 593 3428 Fax.:(+30) 210 684 7881 URL: http://www.reliableembeddedsystems.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ..."It is always easier to ask forgiveness than it is to get permission." - (Amazing) Grace Hopper My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 |
|
From: Alexander P. <gl...@go...> - 2010-06-06 13:43:59
|
Could you please open a bug with the error message you get running your program? This is necessary to figure out which instruction is not recognized by Valgrind. On Sat, Jun 5, 2010 at 11:33 PM, JoSH Lehan <kr...@gm...> wrote: > Hello. A few weeks ago, I asked a question about "illegal > instruction" encountered while running Valgrind on ARM, and got no > response. > > Backing up a little, I wonder if I'm running Valgrind correctly. What > is the preferred way to run Valgrind on ARM? There's a number of > patches floating around, maybe I picked up the wrong one, or got them > out of order. If this is a FAQ, sorry, please point me in the right > direction. > > Thanks! > > Josh > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Alexander Potapenko Software Engineer Google Moscow |
|
From: JoSH L. <kr...@gm...> - 2010-06-05 19:33:06
|
Hello. A few weeks ago, I asked a question about "illegal instruction" encountered while running Valgrind on ARM, and got no response. Backing up a little, I wonder if I'm running Valgrind correctly. What is the preferred way to run Valgrind on ARM? There's a number of patches floating around, maybe I picked up the wrong one, or got them out of order. If this is a FAQ, sorry, please point me in the right direction. Thanks! Josh |
|
From: Bart V. A. <bva...@ac...> - 2010-06-05 12:47:39
|
On Sat, Jun 5, 2010 at 2:52 AM, Jorge Moraleda <jor...@gm...> wrote: > > I got a drd error in one of my programs, and searching on the web I > found the following boost bug report, including a test sample > reporting the same error found with drd. > https://svn.boost.org/trac/boost/ticket/3526 with a similar error. > > There they seem to conclude that this is not a real problem, but I > wanted to get your opinion. I can reproduce the error. I am running > boost 1.43 and valgrind 11150M (with Bart's linker fix, thank you!!!). You are welcome to test Valgrind r11146 or later (unmodified) -- Julian has fixed the "mmap(...) failed in UME with error 22 (Invalid argument)" error message. > This is the test code they provide in the link above. > [ ... ] > This is my valgrind output when compiled with "g++ -l boost_thread main.cpp" > valgrind --tool=drd ./a.out > ==7014== drd, a thread error detector > ==7014== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. > ==7014== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info > ==7014== Command: ./a.out > ==7014== > ==7014== Thread 3: > ==7014== Conflicting store by thread 3 at 0x0504c750 size 8 > ==7014== at 0x4E41A23: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) > [ ... ] Looks like a false positive on current_thread_tls_key to me, so I have added a suppression pattern in r11152. Bart. |
|
From: Jorge M. <jor...@gm...> - 2010-06-05 00:52:14
|
I got a drd error in one of my programs, and searching on the web I found the following boost bug report, including a test sample reporting the same error found with drd. https://svn.boost.org/trac/boost/ticket/3526 with a similar error. There they seem to conclude that this is not a real problem, but I wanted to get your opinion. I can reproduce the error. I am running boost 1.43 and valgrind 11150M (with Bart's linker fix, thank you!!!). This is the test code they provide in the link above. // @file main.cpp #include </usr/local/include/boost/thread.hpp> using namespace boost; class Runner1 { public: void operator()() { sleep(2); } }; class Runner2 { public: void operator()() { sleep(2); } }; int main() { Runner1 r1; Runner2 r2; thread t1(r1); thread t2(r2); t1.join(); t2.join(); } This is my valgrind output when compiled with "g++ -l boost_thread main.cpp" valgrind --tool=drd ./a.out ==7014== drd, a thread error detector ==7014== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==7014== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==7014== Command: ./a.out ==7014== ==7014== Thread 3: ==7014== Conflicting store by thread 3 at 0x0504c750 size 8 ==7014== at 0x4E41A23: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== Allocation context: BSS section of /usr/local/lib/libboost_thread.so.1.43.0 ==7014== Other segment start (thread 2) ==7014== at 0x58C8001: clone (clone.S:84) ==7014== Other segment end (thread 2) ==7014== at 0x5B66734: pthread_once (pthread_once.S:129) ==7014== by 0x4C30E2D: pthread_once (drd_pthread_intercepts.c:516) ==7014== by 0x4E47F43: boost::detail::get_once_per_thread_epoch() (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E4199F: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41D98: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41F54: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7014== by 0x5B608B9: start_thread (pthread_create.c:300) ==7014== by 0x58C803C: clone (clone.S:112) ==7014== ==7014== Conflicting store by thread 3 at 0x0504c750 size 8 ==7014== at 0x4E41A69: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== Allocation context: BSS section of /usr/local/lib/libboost_thread.so.1.43.0 ==7014== Other segment start (thread 2) ==7014== at 0x58C8001: clone (clone.S:84) ==7014== Other segment end (thread 2) ==7014== at 0x5B66734: pthread_once (pthread_once.S:129) ==7014== by 0x4C30E2D: pthread_once (drd_pthread_intercepts.c:516) ==7014== by 0x4E47F43: boost::detail::get_once_per_thread_epoch() (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E4199F: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41D98: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41F54: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7014== by 0x5B608B9: start_thread (pthread_create.c:300) ==7014== by 0x58C803C: clone (clone.S:112) ==7014== Other segment start (thread 2) ==7014== at 0x58C8001: clone (clone.S:84) ==7014== Other segment end (thread 2) ==7014== at 0x5B66734: pthread_once (pthread_once.S:129) ==7014== by 0x4C30E2D: pthread_once (drd_pthread_intercepts.c:516) ==7014== by 0x4E47F43: boost::detail::get_once_per_thread_epoch() (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E4199F: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41D98: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41F54: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7014== by 0x5B608B9: start_thread (pthread_create.c:300) ==7014== by 0x58C803C: clone (clone.S:112) ==7014== ==7014== Conflicting load by thread 3 at 0x05d71288 size 8 ==7014== at 0x5B5FECE: __nptl_deallocate_tsd (pthread_create.c:153) ==7014== Allocation context: BSS section of /lib/libpthread-2.11.1.so ==7014== Other segment start (thread 2) ==7014== at 0x58C8001: clone (clone.S:84) ==7014== Other segment end (thread 2) ==7014== at 0x4C2F283: pthread_mutex_lock (drd_pthread_intercepts.c:578) ==7014== by 0x4E419BB: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41D98: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4E41F54: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7014== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7014== by 0x5B608B9: start_thread (pthread_create.c:300) ==7014== by 0x58C803C: clone (clone.S:112) ==7014== ==7014== ==7014== For counts of detected and suppressed errors, rerun with: -v ==7014== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 66 from 66) |
|
From: R. P. J. <rpj...@gm...> - 2010-06-04 10:49:13
|
As mentioned in the manual, I was able to avoid this by using the* ** --separate-recs=10* . But I am still wondering why we get cycle for new or malloc (because they should never call recursively ) On Thu, Jun 3, 2010 at 4:20 PM, R. P. Janaka <rpj...@gm...> wrote: > Yeah, I checked the manual for avoiding cycle. > > But my question is, if it is due to recursive calls, how does it work for > small number of data set. > And also why does it point it the "*new*" call as a cycle (as I know new > should never go in a cycle) > > > > On Thu, May 20, 2010 at 11:47 PM, Hien Le <Hi...@me...> wrote: > >> > >> > Hi all, >> > >> > I am having an issue with callgrind tool. >> > I am using the valgrind --version: *valgrind-3.1.1* in 32 bit red-hat >> Linux >> > environment. >> > >> > My program is basically document analyzer. What it does is, process the >> > input document and give the result. >> > I just want to analyze my program with callgrind (purpose is to reduce >> the >> > "new" operator calls). >> > >> > The callgrind tool is perfect for it, with small number of documents, >> but it >> > is giving problems with large number of documents. >> > >> > For example, the callgrind output is OK for around 200 documents. But I >> want >> > to do the same analyzes with more than 1000 documents. In that case the >> > callgrind report most of the functions as "*cycle*" even the *new *and >> *malloc >> > *calls. >> > *operator new <cycle 2> >> > malloc <cycle 2> >> > free <cycle 2>* >> > >> > [image: sample callgrind outpu.png] >> > >> > And also it does not show the call flows correctly. >> > This can not happen due to an error in my program, Because it still >> (even >> > after 1000 documents) work perfectly with giving the expected outputs. >> > >> > What could be the reason for this....?? Is this due to the large number >> of >> > calls (exceeding the supported maximum numeric limits ). >> > >> > The following data may be help to identify the issue. >> > >> > For 200 documents >> > - new operator has called 31,452,352 >> > - malloc has called 31,468,098. >> > >> > For around 1000 documents the >> > - new operator has called 1,003,897,109 >> > - malloc has called 1,004,566,498 >> > >> >> >> This section of the manual provides more details on what you are seeing: >> http://valgrind.org/docs/manual/cl-manual.html#cl-manual.cycles >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > > > -- > Regards, > R. P. Janaka > -- Regards, R. P. Janaka |
|
From: R. P. J. <rpj...@gm...> - 2010-06-03 10:50:40
|
Yeah, I checked the manual for avoiding cycle. But my question is, if it is due to recursive calls, how does it work for small number of data set. And also why does it point it the "*new*" call as a cycle (as I know new should never go in a cycle) On Thu, May 20, 2010 at 11:47 PM, Hien Le <Hi...@me...> wrote: > > > > Hi all, > > > > I am having an issue with callgrind tool. > > I am using the valgrind --version: *valgrind-3.1.1* in 32 bit red-hat > Linux > > environment. > > > > My program is basically document analyzer. What it does is, process the > > input document and give the result. > > I just want to analyze my program with callgrind (purpose is to reduce > the > > "new" operator calls). > > > > The callgrind tool is perfect for it, with small number of documents, but > it > > is giving problems with large number of documents. > > > > For example, the callgrind output is OK for around 200 documents. But I > want > > to do the same analyzes with more than 1000 documents. In that case the > > callgrind report most of the functions as "*cycle*" even the *new *and > *malloc > > *calls. > > *operator new <cycle 2> > > malloc <cycle 2> > > free <cycle 2>* > > > > [image: sample callgrind outpu.png] > > > > And also it does not show the call flows correctly. > > This can not happen due to an error in my program, Because it still (even > > after 1000 documents) work perfectly with giving the expected outputs. > > > > What could be the reason for this....?? Is this due to the large number > of > > calls (exceeding the supported maximum numeric limits ). > > > > The following data may be help to identify the issue. > > > > For 200 documents > > - new operator has called 31,452,352 > > - malloc has called 31,468,098. > > > > For around 1000 documents the > > - new operator has called 1,003,897,109 > > - malloc has called 1,004,566,498 > > > > > This section of the manual provides more details on what you are seeing: > http://valgrind.org/docs/manual/cl-manual.html#cl-manual.cycles > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Regards, R. P. Janaka |
|
From: Julian S. <js...@ac...> - 2010-06-03 08:38:52
|
> This means that pthread_cond_broadcast() was called from a global > constructor in libboost_log.so before the initialization function in > vgpreload_drd-amd64-linux.so (DRD_(init)) was called. I was surprised > seeing constructors being called in this order. Julian, is this a > normal behavior of the Valgrind core ? I think this is unrelated to the Valgrind core. If I understand correctly, you're asking about the relative order of calling of a global constructor in vgpreload_drd-amd64-linux.so and a global constructor in libboost_log.so. That is a question for ld.so, and I think in this case you get no guarantees. (but am not sure about that). The fact that ld.so is running on the virtual cpu, not the real one, doesn't matter. J |