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
(20) |
2
(6) |
3
(11) |
4
(1) |
|
5
|
6
(2) |
7
(13) |
8
(14) |
9
(3) |
10
(3) |
11
(2) |
|
12
(4) |
13
|
14
(8) |
15
(6) |
16
(7) |
17
(4) |
18
(3) |
|
19
(5) |
20
(4) |
21
(10) |
22
(6) |
23
|
24
(7) |
25
|
|
26
(6) |
27
(6) |
28
(2) |
29
(4) |
30
(5) |
31
(7) |
|
|
From: Dennis L. <pla...@in...> - 2006-03-15 16:50:33
|
Am Mittwoch, den 15.03.2006, 15:06 +0100 schrieb Ibrahim: > it's an RTAI3.1 under Linux2.6.8 > did u confirm that it valgrind can debug an RTAI/LXRT > process? > btw. ancient kernel... nevertheless, what exactly is rtai? I found rtai.org website, but cannot look at it, as it insists on using https with an invalid certificate. Did you check the source code, if it actual does use that kind of instructions? Do you need some special kernel patches or kernel modules for operating the system? greets Dennis |
|
From: Ibrahim <be_...@ya...> - 2006-03-15 14:06:24
|
--- Julian Seward <js...@ac...> a écrit : > > > vex x86->IR: unhandled instruction bytes: 0xCD > 0xE3 > > 0x89 0x3 > > That's "int $0xE3", which is a pretty strange insn. > Are you how can i interpret this Hexadecimal information!! > doing some strange hardware-related thing? no i don't touch any hardware-related thing! >Or > perhaps it's to > do with your RTAI distribution? it's an RTAI3.1 under Linux2.6.8 did u confirm that it valgrind can debug an RTAI/LXRT process? best regards, > This SF.Net email is sponsored by xPML, a > groundbreaking scripting language > that extends applications into web and mobile media. > Attend the live webcast > and join the prime developer group breaking into > this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 /minute ! Téléchargez sur http://fr.messenger.yahoo.com |
|
From: Ibrahim <be_...@ya...> - 2006-03-15 14:01:50
|
> Your problem is an unhandled instruction, ie one > that Valgrind doesn't > understand: > > > vex x86->IR: unhandled instruction bytes: 0xCD > 0xE3 0x89 0x3 > > No idea what it might be, as I'm purely a user! If > you're not using > 3.1.0 (ie the latest) try that, otherwise try the > code direct from SVN. > There are details on the website (www.valgrind.org) > on how to obtain & > compile both. > > Alasdair i'm using the 3.1.0 version of valgrind (Linux 2.6.8 and RTAI 3.1). what did u mean by SVN??? thanks > > i'm working under linux/RTAI platform and when > > exceuting my application, named "testPropagation" > i > > had a segmentation fault error!! that's why i'm > trying > > valgrind tool for debugging my application. > > the commande line i type: > > > > "valgrind -v ./testPropagation" > > and as it seems there was a problem when > debugging: as > > it seems valgrind has killed my application > because it > > doesn't recognise lxrt library!! > > > > this is the result of the command line above: > > > > ==5579== My PID = 5579, parent PID = 2848. Prog > and > > args are: > > ==5579== ./testPropagation > > ==5579== > > --5579-- > > --5579-- Command line > > --5579-- ./testPropagation > > --5579-- Startup, with flags: > > --5579-- -v > > --5579-- --log-file=memcheckresukt > > --5579-- Contents of /proc/version: > > --5579-- Linux version 2.6.8.1-adeos > > (brahimos@localhost.localdomain) (version gcc > 3.3.3 > > 20040412 (Red Hat Linux 3.3.3-7)) #1 Mon Jan 10 > > 01:42:11 CET 2005 > > --5579-- Arch and subarch: X86, x86-sse2 > > --5579-- Valgrind library directory: > > /usr/local/lib/valgrind > > --5579-- Reading syms from /lib/ld-2.3.3.so > (0xB1A000) > > --5579-- Reading syms from > > /home/brahimos/manip/copie_test4/testPropagation > > (0x8048000) > > --5579-- Reading syms from > > /usr/local/lib/valgrind/x86-linux/memcheck > > (0xB0000000) > > --5579-- object doesn't have a dynamic symbol > table > > --5579-- Reading suppressions file: > > /usr/local/lib/valgrind/default.supp > > --5579-- REDIR: 0xB2B400 (index) redirected to > > 0xB001AE72 (vgPlain_x86_linux_REDIR_FOR_index) > > --5579-- Reading syms from > > > /usr/local/lib/valgrind/x86-linux/vgpreload_core.so > > (0x4000000) > > --5579-- Reading syms from > > > /usr/local/lib/valgrind/x86-linux/vgpreload_memcheck.so > > (0x4003000) > > --5579-- REDIR: 0xB2B5A0 (strlen) redirected to > > 0x4005F8C (strlen) > > --5579-- Reading syms from > /lib/tls/libpthread-0.61.so > > (0xD6C000) > > --5579-- Reading syms from > /usr/lib/libstdc++.so.5.0.5 > > (0x6A16000) > > --5579-- object doesn't have a symbol table > > --5579-- Reading syms from /lib/tls/libm-2.3.3.so > > (0xC54000) > > --5579-- Reading syms from > > /lib/libgcc_s-3.3.3-20040413.so.1 (0xAD3000) > > --5579-- object doesn't have a symbol table > > --5579-- Reading syms from /lib/tls/libc-2.3.3.so > > (0xB37000) > > --5579-- REDIR: 0xB1A7A0 (_dl_sysinfo_int80) > > redirected to 0xB001AE6F (???) > > --5579-- REDIR: 0xB9E880 (memset) redirected to > > 0x4006680 (memset) > > --5579-- REDIR: 0xB9DAE0 (rindex) redirected to > > 0x4005C88 (rindex) > > --5579-- REDIR: 0xB9D250 (strcpy) redirected to > > 0x4005FC4 (strcpy) > > --5579-- REDIR: 0xB9ED50 (memcpy) redirected to > > 0x40062A4 (memcpy) > > --5579-- REDIR: 0xB9D820 (strnlen) redirected to > > 0x4005F4C (strnlen) > > --5579-- REDIR: 0xB97010 (malloc) redirected to > > 0x40043EE (malloc) > > --5579-- REDIR: 0xB9D770 (strlen) redirected to > > 0x4005F70 (strlen) > > --5579-- REDIR: 0x6AA9380 (operator new(unsigned)) > > redirected to 0x4004779 (operator new(unsigned)) > > --5579-- REDIR: 0xB9E820 (memmove) redirected to > > 0x40066A8 (memmove) > > vex x86->IR: unhandled instruction bytes: 0xCD > 0xE3 > > 0x89 0x3 > > ==5579== Your program just tried to execute an > > instruction that Valgrind > > ==5579== did not recognise. There are two > possible > > reasons for this. > > ==5579== 1. Your program has a bug and erroneously > > jumped to a non-code > > ==5579== location. If you are running Memcheck > and > > you just saw a > > ==5579== warning about a bad jump, it's > probably > > your program's fault. > > ==5579== 2. The instruction is legitimate but > Valgrind > > doesn't handle it, > > ==5579== i.e. it's Valgrind's fault. If you > think > > this is the case or > > ==5579== you are not sure, please let us know. > > ==5579== Either way, Valgrind will now raise a > SIGILL > > signal which will > > ==5579== probably kill your program. > > ==5579== > > ==5579== Process terminating with default action > of > > signal 4 (SIGILL) > > ==5579== Illegal opcode at address 0x806B8BB > > ==5579== at 0x806B8BB: _rtai_lxrt (in > > /home/brahimos/manip/copie_test4/testPropagation) > > ==5579== by 0x806BB65: > > TPCommReceptor::TPCommReceptor() (in > > /home/brahimos/manip/copie_test4/testPropagation) > > ==5579== by 0x80688D6: > TokenPlayer::TokenPlayer() > > (in > /home/brahimos/manip/copie_test4/testPropagation) > > ==5579== by 0x8068B5F: > > TokenPlayer::tokenPlayerCreate() (in > > /home/brahimos/manip/copie_test4/testPropagation) > > ==5579== by 0x80642AE: main (in > > /home/brahimos/manip/copie_test4/testPropagation) > > --5579-- REDIR: 0xB996B0 (free) redirected to > > 0x4004EE5 (free) > > ==5579== > > ==5579== ERROR SUMMARY: 0 errors from 0 contexts > > (suppressed: 17 from 1) > > --5579-- > > --5579-- supp: 17 Ugly strchr error in > > /lib/ld-2.3.3.so > > ==5579== malloc/free: in use at exit: 14,084 bytes > in > > 138 blocks. > > ==5579== malloc/free: 138 allocs, 0 frees, 14,084 > > bytes allocated. > > ==5579== > > ==5579== searching for pointers to 138 not-freed > > blocks. > > ==5579== checked 117,764 bytes. > > ==5579== > > ==5579== LEAK SUMMARY: > > ==5579== definitely lost: 20 bytes in 1 blocks. > > ==5579== possibly lost: 472 bytes in 14 > blocks. > > ==5579== still reachable: 13,592 bytes in 123 > > blocks. > > ==5579== suppressed: 0 bytes in 0 blocks. > > ==5579== Use --leak-check=full to see details of > > leaked memory. > > --5579-- memcheck: sanity checks: 6 cheap, 1 > > expensive > > --5579-- memcheck: auxmaps: 0 auxmap entries (0k, > 0M) > > in use > > --5579-- memcheck: auxmaps: 0 searches, 0 > comparisons > > --5579-- memcheck: secondaries: 18 issued (1152k, > 1M) > > --5579-- memcheck: secondaries: 29 accessible and > > distinguished (1856k, 1M) > > --5579-- tt/tc: 8,836 tt lookups requiring > 9,121 > > probes > > --5579-- tt/tc: 8,836 fast-cache updates, 3 > === message truncated === ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com |
|
From: Julian S. <js...@ac...> - 2006-03-15 10:54:30
|
> vex x86->IR: unhandled instruction bytes: 0xCD 0xE3 > 0x89 0x3 That's "int $0xE3", which is a pretty strange insn. Are you doing some strange hardware-related thing? Or perhaps it's to do with your RTAI distribution? J |
|
From: Alasdair F. <ala...@sp...> - 2006-03-15 08:01:18
|
Ibrahim, Your problem is an unhandled instruction, ie one that Valgrind doesn't understand: > vex x86->IR: unhandled instruction bytes: 0xCD 0xE3 0x89 0x3 No idea what it might be, as I'm purely a user! If you're not using 3.1.0 (ie the latest) try that, otherwise try the code direct from SVN. There are details on the website (www.valgrind.org) on how to obtain & compile both. Alasdair > i'm working under linux/RTAI platform and when > exceuting my application, named "testPropagation" i > had a segmentation fault error!! that's why i'm trying > valgrind tool for debugging my application. > the commande line i type: > > "valgrind -v ./testPropagation" > and as it seems there was a problem when debugging: as > it seems valgrind has killed my application because it > doesn't recognise lxrt library!! > > this is the result of the command line above: > > ==5579== My PID = 5579, parent PID = 2848. Prog and > args are: > ==5579== ./testPropagation > ==5579== > --5579-- > --5579-- Command line > --5579-- ./testPropagation > --5579-- Startup, with flags: > --5579-- -v > --5579-- --log-file=memcheckresukt > --5579-- Contents of /proc/version: > --5579-- Linux version 2.6.8.1-adeos > (brahimos@localhost.localdomain) (version gcc 3.3.3 > 20040412 (Red Hat Linux 3.3.3-7)) #1 Mon Jan 10 > 01:42:11 CET 2005 > --5579-- Arch and subarch: X86, x86-sse2 > --5579-- Valgrind library directory: > /usr/local/lib/valgrind > --5579-- Reading syms from /lib/ld-2.3.3.so (0xB1A000) > --5579-- Reading syms from > /home/brahimos/manip/copie_test4/testPropagation > (0x8048000) > --5579-- Reading syms from > /usr/local/lib/valgrind/x86-linux/memcheck > (0xB0000000) > --5579-- object doesn't have a dynamic symbol table > --5579-- Reading suppressions file: > /usr/local/lib/valgrind/default.supp > --5579-- REDIR: 0xB2B400 (index) redirected to > 0xB001AE72 (vgPlain_x86_linux_REDIR_FOR_index) > --5579-- Reading syms from > /usr/local/lib/valgrind/x86-linux/vgpreload_core.so > (0x4000000) > --5579-- Reading syms from > /usr/local/lib/valgrind/x86-linux/vgpreload_memcheck.so > (0x4003000) > --5579-- REDIR: 0xB2B5A0 (strlen) redirected to > 0x4005F8C (strlen) > --5579-- Reading syms from /lib/tls/libpthread-0.61.so > (0xD6C000) > --5579-- Reading syms from /usr/lib/libstdc++.so.5.0.5 > (0x6A16000) > --5579-- object doesn't have a symbol table > --5579-- Reading syms from /lib/tls/libm-2.3.3.so > (0xC54000) > --5579-- Reading syms from > /lib/libgcc_s-3.3.3-20040413.so.1 (0xAD3000) > --5579-- object doesn't have a symbol table > --5579-- Reading syms from /lib/tls/libc-2.3.3.so > (0xB37000) > --5579-- REDIR: 0xB1A7A0 (_dl_sysinfo_int80) > redirected to 0xB001AE6F (???) > --5579-- REDIR: 0xB9E880 (memset) redirected to > 0x4006680 (memset) > --5579-- REDIR: 0xB9DAE0 (rindex) redirected to > 0x4005C88 (rindex) > --5579-- REDIR: 0xB9D250 (strcpy) redirected to > 0x4005FC4 (strcpy) > --5579-- REDIR: 0xB9ED50 (memcpy) redirected to > 0x40062A4 (memcpy) > --5579-- REDIR: 0xB9D820 (strnlen) redirected to > 0x4005F4C (strnlen) > --5579-- REDIR: 0xB97010 (malloc) redirected to > 0x40043EE (malloc) > --5579-- REDIR: 0xB9D770 (strlen) redirected to > 0x4005F70 (strlen) > --5579-- REDIR: 0x6AA9380 (operator new(unsigned)) > redirected to 0x4004779 (operator new(unsigned)) > --5579-- REDIR: 0xB9E820 (memmove) redirected to > 0x40066A8 (memmove) > vex x86->IR: unhandled instruction bytes: 0xCD 0xE3 > 0x89 0x3 > ==5579== Your program just tried to execute an > instruction that Valgrind > ==5579== did not recognise. There are two possible > reasons for this. > ==5579== 1. Your program has a bug and erroneously > jumped to a non-code > ==5579== location. If you are running Memcheck and > you just saw a > ==5579== warning about a bad jump, it's probably > your program's fault. > ==5579== 2. The instruction is legitimate but Valgrind > doesn't handle it, > ==5579== i.e. it's Valgrind's fault. If you think > this is the case or > ==5579== you are not sure, please let us know. > ==5579== Either way, Valgrind will now raise a SIGILL > signal which will > ==5579== probably kill your program. > ==5579== > ==5579== Process terminating with default action of > signal 4 (SIGILL) > ==5579== Illegal opcode at address 0x806B8BB > ==5579== at 0x806B8BB: _rtai_lxrt (in > /home/brahimos/manip/copie_test4/testPropagation) > ==5579== by 0x806BB65: > TPCommReceptor::TPCommReceptor() (in > /home/brahimos/manip/copie_test4/testPropagation) > ==5579== by 0x80688D6: TokenPlayer::TokenPlayer() > (in /home/brahimos/manip/copie_test4/testPropagation) > ==5579== by 0x8068B5F: > TokenPlayer::tokenPlayerCreate() (in > /home/brahimos/manip/copie_test4/testPropagation) > ==5579== by 0x80642AE: main (in > /home/brahimos/manip/copie_test4/testPropagation) > --5579-- REDIR: 0xB996B0 (free) redirected to > 0x4004EE5 (free) > ==5579== > ==5579== ERROR SUMMARY: 0 errors from 0 contexts > (suppressed: 17 from 1) > --5579-- > --5579-- supp: 17 Ugly strchr error in > /lib/ld-2.3.3.so > ==5579== malloc/free: in use at exit: 14,084 bytes in > 138 blocks. > ==5579== malloc/free: 138 allocs, 0 frees, 14,084 > bytes allocated. > ==5579== > ==5579== searching for pointers to 138 not-freed > blocks. > ==5579== checked 117,764 bytes. > ==5579== > ==5579== LEAK SUMMARY: > ==5579== definitely lost: 20 bytes in 1 blocks. > ==5579== possibly lost: 472 bytes in 14 blocks. > ==5579== still reachable: 13,592 bytes in 123 > blocks. > ==5579== suppressed: 0 bytes in 0 blocks. > ==5579== Use --leak-check=full to see details of > leaked memory. > --5579-- memcheck: sanity checks: 6 cheap, 1 > expensive > --5579-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) > in use > --5579-- memcheck: auxmaps: 0 searches, 0 comparisons > --5579-- memcheck: secondaries: 18 issued (1152k, 1M) > --5579-- memcheck: secondaries: 29 accessible and > distinguished (1856k, 1M) > --5579-- tt/tc: 8,836 tt lookups requiring 9,121 > probes > --5579-- tt/tc: 8,836 fast-cache updates, 3 > flushes > --5579-- translate: new 4,299 (99,337 -> > 1,740,262; ratio 175:10) [0 scs] > --5579-- translate: dumped 0 (0 -> ??) > --5579-- translate: discarded 8 (187 -> ??) > --5579-- scheduler: 343,044 jumps (bb entries). > --5579-- scheduler: 6/4,780 major/minor sched events. > --5579-- sanity: 7 cheap, 1 expensive checks. > --5579-- exectx: 30,011 lists, 146 contexts (avg 0 > per list) > --5579-- exectx: 155 searches, 9 full compares (58 > per 1000) > --5579-- exectx: 0 cmp2, 49 cmp4, 0 cmpAll > -- ------------------------------------------------------------------------ Alasdair Ferro SpiraTech Ltd, Product Engineer Carrington Business Park, mailto:ala...@sp... Manchester, Work: +44 (0)161 776 4582 M31 4DD, U.K. http://www.spiratech.com ------------------------------------------------------------------------ This email and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed. If you have received this in error, please contact the sender and delete the material immediately. Whilst this email has been swept for viruses, you should carry out your own virus check before opening any attachment. SpiraTech Ltd accepts no liability for any loss or damage which may be caused by software viruses or interception or interruption of this email. |
|
From: Nicholas N. <nj...@cs...> - 2006-03-14 23:56:33
|
On Tue, 14 Mar 2006, Patrick Rabau wrote: > Does valgrind provide a way to print the max used size of the stack, > i.e., how big the stack utilization grew for a program run (at least > for the main stack if on a multithreaded application)? This is useful > to know if the stack was sized appropriately. Massif (use --tool=massif) will give you an idea about this. Nick |
|
From: Ibrahim <be_...@ya...> - 2006-03-14 23:46:32
|
hi, i'm working under linux/RTAI platform and when exceuting my application, named "testPropagation" i had a segmentation fault error!! that's why i'm trying valgrind tool for debugging my application. the commande line i type: "valgrind -v ./testPropagation" and as it seems there was a problem when debugging: as it seems valgrind has killed my application because it doesn't recognise lxrt library!! this is the result of the command line above: ==5579== My PID = 5579, parent PID = 2848. Prog and args are: ==5579== ./testPropagation ==5579== --5579-- --5579-- Command line --5579-- ./testPropagation --5579-- Startup, with flags: --5579-- -v --5579-- --log-file=memcheckresukt --5579-- Contents of /proc/version: --5579-- Linux version 2.6.8.1-adeos (brahimos@localhost.localdomain) (version gcc 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 Mon Jan 10 01:42:11 CET 2005 --5579-- Arch and subarch: X86, x86-sse2 --5579-- Valgrind library directory: /usr/local/lib/valgrind --5579-- Reading syms from /lib/ld-2.3.3.so (0xB1A000) --5579-- Reading syms from /home/brahimos/manip/copie_test4/testPropagation (0x8048000) --5579-- Reading syms from /usr/local/lib/valgrind/x86-linux/memcheck (0xB0000000) --5579-- object doesn't have a dynamic symbol table --5579-- Reading suppressions file: /usr/local/lib/valgrind/default.supp --5579-- REDIR: 0xB2B400 (index) redirected to 0xB001AE72 (vgPlain_x86_linux_REDIR_FOR_index) --5579-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_core.so (0x4000000) --5579-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4003000) --5579-- REDIR: 0xB2B5A0 (strlen) redirected to 0x4005F8C (strlen) --5579-- Reading syms from /lib/tls/libpthread-0.61.so (0xD6C000) --5579-- Reading syms from /usr/lib/libstdc++.so.5.0.5 (0x6A16000) --5579-- object doesn't have a symbol table --5579-- Reading syms from /lib/tls/libm-2.3.3.so (0xC54000) --5579-- Reading syms from /lib/libgcc_s-3.3.3-20040413.so.1 (0xAD3000) --5579-- object doesn't have a symbol table --5579-- Reading syms from /lib/tls/libc-2.3.3.so (0xB37000) --5579-- REDIR: 0xB1A7A0 (_dl_sysinfo_int80) redirected to 0xB001AE6F (???) --5579-- REDIR: 0xB9E880 (memset) redirected to 0x4006680 (memset) --5579-- REDIR: 0xB9DAE0 (rindex) redirected to 0x4005C88 (rindex) --5579-- REDIR: 0xB9D250 (strcpy) redirected to 0x4005FC4 (strcpy) --5579-- REDIR: 0xB9ED50 (memcpy) redirected to 0x40062A4 (memcpy) --5579-- REDIR: 0xB9D820 (strnlen) redirected to 0x4005F4C (strnlen) --5579-- REDIR: 0xB97010 (malloc) redirected to 0x40043EE (malloc) --5579-- REDIR: 0xB9D770 (strlen) redirected to 0x4005F70 (strlen) --5579-- REDIR: 0x6AA9380 (operator new(unsigned)) redirected to 0x4004779 (operator new(unsigned)) --5579-- REDIR: 0xB9E820 (memmove) redirected to 0x40066A8 (memmove) vex x86->IR: unhandled instruction bytes: 0xCD 0xE3 0x89 0x3 ==5579== Your program just tried to execute an instruction that Valgrind ==5579== did not recognise. There are two possible reasons for this. ==5579== 1. Your program has a bug and erroneously jumped to a non-code ==5579== location. If you are running Memcheck and you just saw a ==5579== warning about a bad jump, it's probably your program's fault. ==5579== 2. The instruction is legitimate but Valgrind doesn't handle it, ==5579== i.e. it's Valgrind's fault. If you think this is the case or ==5579== you are not sure, please let us know. ==5579== Either way, Valgrind will now raise a SIGILL signal which will ==5579== probably kill your program. ==5579== ==5579== Process terminating with default action of signal 4 (SIGILL) ==5579== Illegal opcode at address 0x806B8BB ==5579== at 0x806B8BB: _rtai_lxrt (in /home/brahimos/manip/copie_test4/testPropagation) ==5579== by 0x806BB65: TPCommReceptor::TPCommReceptor() (in /home/brahimos/manip/copie_test4/testPropagation) ==5579== by 0x80688D6: TokenPlayer::TokenPlayer() (in /home/brahimos/manip/copie_test4/testPropagation) ==5579== by 0x8068B5F: TokenPlayer::tokenPlayerCreate() (in /home/brahimos/manip/copie_test4/testPropagation) ==5579== by 0x80642AE: main (in /home/brahimos/manip/copie_test4/testPropagation) --5579-- REDIR: 0xB996B0 (free) redirected to 0x4004EE5 (free) ==5579== ==5579== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1) --5579-- --5579-- supp: 17 Ugly strchr error in /lib/ld-2.3.3.so ==5579== malloc/free: in use at exit: 14,084 bytes in 138 blocks. ==5579== malloc/free: 138 allocs, 0 frees, 14,084 bytes allocated. ==5579== ==5579== searching for pointers to 138 not-freed blocks. ==5579== checked 117,764 bytes. ==5579== ==5579== LEAK SUMMARY: ==5579== definitely lost: 20 bytes in 1 blocks. ==5579== possibly lost: 472 bytes in 14 blocks. ==5579== still reachable: 13,592 bytes in 123 blocks. ==5579== suppressed: 0 bytes in 0 blocks. ==5579== Use --leak-check=full to see details of leaked memory. --5579-- memcheck: sanity checks: 6 cheap, 1 expensive --5579-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --5579-- memcheck: auxmaps: 0 searches, 0 comparisons --5579-- memcheck: secondaries: 18 issued (1152k, 1M) --5579-- memcheck: secondaries: 29 accessible and distinguished (1856k, 1M) --5579-- tt/tc: 8,836 tt lookups requiring 9,121 probes --5579-- tt/tc: 8,836 fast-cache updates, 3 flushes --5579-- translate: new 4,299 (99,337 -> 1,740,262; ratio 175:10) [0 scs] --5579-- translate: dumped 0 (0 -> ??) --5579-- translate: discarded 8 (187 -> ??) --5579-- scheduler: 343,044 jumps (bb entries). --5579-- scheduler: 6/4,780 major/minor sched events. --5579-- sanity: 7 cheap, 1 expensive checks. --5579-- exectx: 30,011 lists, 146 contexts (avg 0 per list) --5579-- exectx: 155 searches, 9 full compares (58 per 1000) --5579-- exectx: 0 cmp2, 49 cmp4, 0 cmpAll thanks for any help, Ibrahim ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com |
|
From: Patrick R. <pr...@gm...> - 2006-03-14 23:37:34
|
Hi, Does valgrind provide a way to print the max used size of the stack, i.e., how big the stack utilization grew for a program run (at least for the main stack if on a multithreaded application)? This is useful to know if the stack was sized appropriately. Patrick |
|
From: <Tam...@er...> - 2006-03-14 17:20:04
|
Hi,
I'm trying to debug my Java native methods using Valgrind. =
Unfortunately, it doesn't seem to work.
When I start my test application Valgrind starts OK as well. But then it =
stops producing printouts. After that my program finishes without =
problems (but Valgrind printouts are missing).
I use Sun JVM 1.4.2.06 and Valgrind 3.1 on a SuSE Linux with 2.6.5 =
kernel.
Here is the printout I get when running my test application:
mwlx124> /export/localhome/ltameil/Documents/valgrind/bin/valgrind =
--leak-check=3Dfull =
/export/localhome/ltameil/Documents/j2sdk1.4.2_05/jre/bin/java jnitest
=3D=3D4953=3D=3D Memcheck, a memory error detector.
=3D=3D4953=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian =
Seward et al.
=3D=3D4953=3D=3D Using LibVEX rev 1471, a library for dynamic binary =
translation.
=3D=3D4953=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks =
LLP.
=3D=3D4953=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation =
framework.
=3D=3D4953=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian =
Seward et al.
=3D=3D4953=3D=3D For more details, rerun with: -v
=3D=3D4953=3D=3D
=3D=3D4953=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D4953=3D=3D at 0x4001532: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40017C9: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D
=3D=3D4953=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D4953=3D=3D at 0x400156D: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40017C9: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D
=3D=3D4953=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D4953=3D=3D at 0x400E303: strlen (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400476C: _dl_init_paths (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40029B8: dl_main (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400CC49: _dl_sysdep_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400190E: _dl_start_final (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40017F5: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D
=3D=3D4953=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D4953=3D=3D at 0x4008F21: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40091FA: _dl_relocate_object (in =
/lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001FF1: dl_main (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400CC49: _dl_sysdep_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400190E: _dl_start_final (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40017F5: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D
=3D=3D4953=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D4953=3D=3D at 0x4008F25: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40091FA: _dl_relocate_object (in =
/lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001FF1: dl_main (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400CC49: _dl_sysdep_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x400190E: _dl_start_final (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x40017F5: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D4953=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
This is Java_jnitest_printHello
exit...
mwlx124>
Here is the code of the native method I try to debug:
JNIEXPORT void JNICALL=20
Java_jnitest_printHello (JNIEnv *env, jobject obj) {
void* p;
int i;
printf("This is Java_jnitest_printHello\n");
for (i=3D0; i<10; i++){
p =3D malloc(1000);
}
printf("exit...\n");
}
If I do the same in a pure C program Valgrind says that there is 10000 =
bytes are definitely lost and syas that "searching for pointers to 10 =
not-freed blocks".
Here is the code:
#include <stdlib.h>
#include <stdio.h>
int main(int argc,const char* argv[]) {
int i;
void* p;
=20
printf("Start...\n");
for (i=3D0; i<10; i++) {
p =3D malloc(1000);
}
printf("Stop.\n");
}
And the printouts:
mwlx124> /export/localhome/ltameil/Documents/valgrind/bin/valgrind =
--leak-check=3Dfull ./ctest
=3D=3D5065=3D=3D Memcheck, a memory error detector.
=3D=3D5065=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian =
Seward et al.
=3D=3D5065=3D=3D Using LibVEX rev 1471, a library for dynamic binary =
translation.
=3D=3D5065=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks =
LLP.
=3D=3D5065=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation =
framework.
=3D=3D5065=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian =
Seward et al.
=3D=3D5065=3D=3D For more details, rerun with: -v
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D5065=3D=3D at 0x4001532: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40017C9: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D5065=3D=3D at 0x400156D: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40017C9: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D5065=3D=3D at 0x400E303: strlen (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400476C: _dl_init_paths (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40029B8: dl_main (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400CC49: _dl_sysdep_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400190E: _dl_start_final (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40017F5: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D5065=3D=3D at 0x4008F21: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40091FA: _dl_relocate_object (in =
/lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001FF1: dl_main (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400CC49: _dl_sysdep_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400190E: _dl_start_final (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40017F5: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D5065=3D=3D at 0x4008F25: elf_dynamic_do_rel.4 (in =
/lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40091FA: _dl_relocate_object (in =
/lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001FF1: dl_main (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400CC49: _dl_sysdep_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x400190E: _dl_start_final (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x40017F5: _dl_start (in /lib/ld-2.2.5.so)
=3D=3D5065=3D=3D by 0x4001305: (within /lib/ld-2.2.5.so)
Start...
Stop.
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 =
from 0)
=3D=3D5065=3D=3D malloc/free: in use at exit: 10,000 bytes in 10 blocks.
=3D=3D5065=3D=3D malloc/free: 10 allocs, 0 frees, 10,000 bytes =
allocated.
=3D=3D5065=3D=3D For counts of detected errors, rerun with: -v
=3D=3D5065=3D=3D searching for pointers to 10 not-freed blocks.
=3D=3D5065=3D=3D checked 69,120 bytes.
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D 10,000 bytes in 10 blocks are definitely lost in loss =
record 1 of 1
=3D=3D5065=3D=3D at 0x401862A: malloc =
(m_replacemalloc/vg_replace_malloc.c:149)
=3D=3D5065=3D=3D by 0x80483A7: main (in =
/export/localhome/ltameil/Documents/test/jni/ctest)
=3D=3D5065=3D=3D
=3D=3D5065=3D=3D LEAK SUMMARY:
=3D=3D5065=3D=3D definitely lost: 10,000 bytes in 10 blocks.
=3D=3D5065=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D5065=3D=3D still reachable: 0 bytes in 0 blocks.
=3D=3D5065=3D=3D suppressed: 0 bytes in 0 blocks.
=3D=3D5065=3D=3D Reachable blocks (those to which a pointer was found) =
are not shown.
=3D=3D5065=3D=3D To see them, rerun with: --show-reachable=3Dyes
mwlx124>
As far as I know (and as I have experienced so far) the JVM has its own =
memory management mechanism. Is it possible that this mechanism confuses =
Valgrind and that's why it cannot reveal anything?? I know that Valgrind =
should still work in this case too (this is stated on its website) but =
still! Is it possible that Valgrind can't debug Java native methods? (at =
least with this JVM)
Or am I doing something wrong? Do I need special settings??
It would also be useful if someone said: No, Valgrind is not able to =
debug Java native methods... (if this is really the case).
Thanks in advance!
/Tam=E1s
|
|
From: Igmar P. <mai...@jd...> - 2006-03-14 10:00:57
|
> What does this sequence do? If there is a known workaround, please let > me know, Use a more recent version (from svn). Igmar |
|
From: Nicholas N. <nj...@cs...> - 2006-03-14 01:35:28
|
On Mon, 13 Mar 2006, Graydon Hoare wrote: > I've performed a large-ish run (several hours) with massif, and I find that > the numbers which come out of its html results don't seem to add up. For > example, in this profile entry: > > http://people.mozilla.com/~graydon/results/massif.9425.html#b61F64278 > > 3.3 + 3.0 + 2.8 + 1.7 + 1.1 + 1.1 = 13%, yet the entry is supposedly only > responsible for 5.1%. How am I to interpret this? Is it an arithmetic error? > Are the contexts relative portions (eg. is the 13% listed supposed to be > 13%-of-the-5%?) and if so, where is the rest? > > On shorter runs, the numbers appear to add up, so I am thinking this is a > cumulative arithmetic error of some sort. I wonder if anyone else has seen > such things. I think (from what I remember, and judging from the manual) that the percentages are all absolute, ie. a proportion of the total spacetime. So this does look strange. It's possible sometimes that the allocation tree is actually a dag if function pointers are involved. I wonder if that might be confusing Massif in such a way that it does some kind of double-counting somewhere. Nick |
|
From: Graydon H. <gr...@po...> - 2006-03-14 01:12:53
|
Hi, I've performed a large-ish run (several hours) with massif, and I find that the numbers which come out of its html results don't seem to add up. For example, in this profile entry: http://people.mozilla.com/~graydon/results/massif.9425.html#b61F64278 3.3 + 3.0 + 2.8 + 1.7 + 1.1 + 1.1 = 13%, yet the entry is supposedly only responsible for 5.1%. How am I to interpret this? Is it an arithmetic error? Are the contexts relative portions (eg. is the 13% listed supposed to be 13%-of-the-5%?) and if so, where is the rest? On shorter runs, the numbers appear to add up, so I am thinking this is a cumulative arithmetic error of some sort. I wonder if anyone else has seen such things. Thanks, -graydon |
|
From: Yin, H. <hu...@me...> - 2006-03-14 00:18:48
|
=3D=3D6597=3D=3D Memcheck, a memory error detector. =3D=3D6597=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D6597=3D=3D Using LibVEX rev 1471, a library for dynamic binary translation. =3D=3D6597=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks = LLP. =3D=3D6597=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation framework. =3D=3D6597=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D6597=3D=3D For more details, rerun with: -v =3D=3D6597=3D=3D host: Linux underdog 2.4.21-211-smp #1 SMP Fri Apr 2 21:29:13 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux =20 What does this sequence do? If there is a known workaround, please let me know, =20 Thanks, --Hui =20 |
|
From: Josef W. <Jos...@gm...> - 2006-03-12 23:20:29
|
On Saturday 11 March 2006 23:56, Karim Bernardet wrote: > Is there a tool (like kcachegrind) which can generate automatically html > files with the callgrind outputs (a command line in a script to produce > the html files) ? Currently not. It is on my todo list to improve callgrind_annotate. I can imagine to add some kind of XML output (to get HTML with further postprocessing), but it is not really a priority. Josef > > Thanks ! > > Karim > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Bryan M. <om...@br...> - 2006-03-12 16:36:36
|
Dennis, thanks for the suggestion - I personally think it is an excellent idea. The only way to make something like that work without drowning in the output of 10,000 free()d pointers would be to introduce a new client request to mark the memory block after it is created. As each tracked pointer is then added or removed, a trace report could be generated. If I get enough interest in this tool, I will look to implementing this as a feature before the 1.0 release. thanks, Bryan "Brain Murders" Meredith Dennis Lubert wrote: > Am Sonntag, den 12.03.2006, 15:32 +0000 schrieb Bryan Meredith: > >> Omega addresses what I perceive to be one of the few shortfalls of the >> excellent Valgrind Memcheck Tool - where Memcheck reports the location >> that a leaked block was allocated, Omega also shows where it was leaked. > > Not that its bad to do that, but I think its better to say "Omega shows > also where the last pointer/reference to the allocated memory was lost". > Saying "I know were the memory was leaked" would imply to infer the > ownership of the object for the cases multiple pointers refer to it. Who > knows, maybe the pointer that would have been the one responsible to > free the memory has been lost way before another one that has been > copied around is lost. > So, maybe Omega could be extended to give (optional of course) reports > on where pointers to that memory were lost, in order to better figure > out where you should have freed it. > > greets > > Dennis > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Dennis L. <pla...@in...> - 2006-03-12 16:22:18
|
Am Sonntag, den 12.03.2006, 15:32 +0000 schrieb Bryan Meredith: > Omega addresses what I perceive to be one of the few shortfalls of the > excellent Valgrind Memcheck Tool - where Memcheck reports the location > that a leaked block was allocated, Omega also shows where it was leaked. Not that its bad to do that, but I think its better to say "Omega shows also where the last pointer/reference to the allocated memory was lost". Saying "I know were the memory was leaked" would imply to infer the ownership of the object for the cases multiple pointers refer to it. Who knows, maybe the pointer that would have been the one responsible to free the memory has been lost way before another one that has been copied around is lost. So, maybe Omega could be extended to give (optional of course) reports on where pointers to that memory were lost, in order to better figure out where you should have freed it. greets Dennis |
|
From: Bryan M. <om...@br...> - 2006-03-12 15:33:20
|
see http://www.brainmurders.eclipse.co.uk/omega.html for a complete overview of what this tool can do for you. From the web page: ----------------------------------- Omega addresses what I perceive to be one of the few shortfalls of the excellent Valgrind Memcheck Tool - where Memcheck reports the location that a leaked block was allocated, Omega also shows where it was leaked. . . . OK. Let's run Memcheck and Omega on a small test program so you can see what to expect. 01 #include <stdlib.h> 02 03 static void func1(void) 04 { 05 char *pointer = 0; 06 07 pointer = malloc(64); 08 09 return; 10 } /* Leak report here */ 11 12 int main(int argc, char *argv[]) 13 { 14 func1(); 15 16 return 0; 17 } 18 Save that (without the line numbers) as scope2.c then compile it like this: $> gcc -g -O0 scope2.c -o scope . . . $> valgrind --tool=memcheck --leak-check=full ./scope ==13293== Memcheck, a memory error detector. ==13293== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==13293== Using LibVEX rev 1419, a library for dynamic binary translation. ==13293== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==13293== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation framework. ==13293== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==13293== For more details, rerun with: -v ==13293== ==13293== ==13293== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) ==13293== malloc/free: in use at exit: 64 bytes in 1 blocks. ==13293== malloc/free: 1 allocs, 0 frees, 64 bytes allocated. ==13293== For counts of detected errors, rerun with: -v ==13293== searching for pointers to 1 not-freed blocks. ==13293== checked 56,168 bytes. ==13293== ==13293== 64 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==13293== at 0x401B51E: malloc (vg_replace_malloc.c:149) ==13293== by 0x8048372: func1 (scope2.c:7) ==13293== by 0x804838F: main (scope2.c:14) ==13293== ==13293== LEAK SUMMARY: ==13293== definitely lost: 64 bytes in 1 blocks. ==13293== possibly lost: 0 bytes in 0 blocks. ==13293== still reachable: 0 bytes in 0 blocks. ==13293== suppressed: 0 bytes in 0 blocks. ==13293== Reachable blocks (those to which a pointer was found) are not shown. ==13293== To see them, rerun with: --show-reachable=yes As expected, Memcheck identifies that the block allocated at line 7 has leaked. Whilst with this trivial example, its obvious where the leak occurred, tracking down memory leaks can be a really tedious and time consuming exercise. So, lets try Omega to see if it can help us out: $> valgrind --tool=omega ./scope ==13297== Omega-beta2, An instant memory leak detector. ==13297== Copyright (C) 2006, and GNU GPL'd, by Bryan Meredith. ==13297== Using LibVEX rev 1419, a library for dynamic binary translation. ==13297== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==13297== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation framework. ==13297== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==13297== For more details, rerun with: -v ==13297== ==13297== ==13297== ==13297== ==13297== Omega Leak Summary ==13297== ================== ==13297== Loss Record 1: Leaked 64 (0x40) bytes in 1 block ==13297== at 0x8048379: func1 (scope2.c:10) ==13297== by 0x804838F: main (scope2.c:14) ==13297== Block allocated ==13297== at 0x401AE7E: malloc (vg_replace_malloc.c:149) ==13297== by 0x8048372: func1 (scope2.c:7) ==13297== by 0x804838F: main (scope2.c:14) ==13297== See the difference? Omega not only shows that the block allocated at line 7 leaked, it shows you that it leaked at line 10. . . . Omega is NOT perfect. I hope that it will get better but it is fairly usable NOW. It currently supports x86 and x86_64. The main area that I expect to work on to get this up to release standards is function wrapping. With the highly optimised routines in glibc and other libraries, Omega can sometimes lose track of a pointer as it gets moved or miss making a new one on a copy. By introducing function wrappers around these problem functions, we should be able to ensure that the right thing happens. I would welcome assistance to make this work on PPC32 and PPC64 but I have no hardware to test or build on so I would need patches rather than just helpful advice. I am more than happy to receive your comments, criticisms, bug reports and especially patches (although I make no promises to accept them). Any success stories would also be nice to hear about. ----------------------------------- All the information that you need to download, compile and run Omega is on the web page. If you are having problems tracking down memory leaks, Omega is designed to help YOU. Bryan "Brain Murders" Meredith |
|
From: Karim B. <kar...@gm...> - 2006-03-11 22:59:49
|
Hi Is there a tool (like kcachegrind) which can generate automatically html files with the callgrind outputs (a command line in a script to produce the html files) ? Thanks ! Karim |
|
From: Mathieu M. <mat...@gm...> - 2006-03-11 04:44:46
|
Hello,
Just to make sure this is correct. Could someone confirm that I can
safely add a suppression for the following(*). This is caused by the
following program(**)
I am using valgrind:
$ valgrind --version
valgrind-3.1.0-Debian
I believe this should be added in the default suppression file for debia=
n
? Or is there something smarter to do.
Thanks
Mathieu
(*)
=3D=3D15519=3D=3D 1 errors in context 3 of 3:
=3D=3D15519=3D=3D Invalid read of size 4
=3D=3D15519=3D=3D at 0x4010FA3: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x40049C1: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x400654A: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x410BCE0: dl_open_worker (dl-open.c:259)
=3D=3D15519=3D=3D by 0x400B056: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x410C5C4: _dl_open (dl-open.c:577)
=3D=3D15519=3D=3D by 0x401FD2E: dlopen_doit (dlopen.c:59)
=3D=3D15519=3D=3D by 0x400B056: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x40202FF: _dlerror_run (dlerror.c:162)
=3D=3D15519=3D=3D by 0x401FD9C: dlopen@@GLIBC_2.1 (dlopen.c:78)
=3D=3D15519=3D=3D by 0x8048603: main (test.c:7)
=3D=3D15519=3D=3D Address 0x4152038 is 16 bytes inside a block of size 17 =
alloc'd
=3D=3D15519=3D=3D at 0x401B422: malloc (vg_replace_malloc.c:149)
=3D=3D15519=3D=3D by 0x4006752: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x410BCE0: dl_open_worker (dl-open.c:259)
=3D=3D15519=3D=3D by 0x400B056: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x410C5C4: _dl_open (dl-open.c:577)
=3D=3D15519=3D=3D by 0x401FD2E: dlopen_doit (dlopen.c:59)
=3D=3D15519=3D=3D by 0x400B056: (within /lib/ld-2.3.5.so)
=3D=3D15519=3D=3D by 0x40202FF: _dlerror_run (dlerror.c:162)
=3D=3D15519=3D=3D by 0x401FD9C: dlopen@@GLIBC_2.1 (dlopen.c:78)
=3D=3D15519=3D=3D by 0x8048603: main (test.c:7)
(**)
#include <dlfcn.h>
#include <stdio.h>
int main(/*int argc , char *argv[]*/)
{
const char filename[] =3D "libz.so";
void *libhandle =3D dlopen(filename, RTLD_LAZY);
/*printf( "dlopen: %d\n", (int)libhandle);*/
if(!libhandle) return 1;
const char symbol[] =3D "gzopen";
void* address =3D dlsym(libhandle, symbol);
/*printf( "dlsym: %d\n", (int)address);*/
if(!address) return 1;
int res =3D 0;
if(libhandle)
{
res =3D !dlclose(libhandle);
}
/*printf( "dlclose: %d\n", res);*/
if(!res) return 1;
return 0;
}
--
Mathieu
|
|
From: Christoph B. <bar...@or...> - 2006-03-10 12:11:53
|
Hi, do the macros VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK automatically mark the block as writable but not defined as VALGRIND_MAKE_WRITABLE does it? Christoph |
|
From: Mayukh B. <ma...@gm...> - 2006-03-10 06:17:41
|
Julian Seward <jseward <at> acm.org> writes: > > > Whoa! That's ancient. I suggest you upgrade to 3.1.0 and try again. > > J > You were right. 3.1.0 does not have this problem. Thank you, -Mayukh. |
|
From: Nicholas N. <nj...@cs...> - 2006-03-10 04:08:45
|
On Thu, 9 Mar 2006 val...@ce... wrote: > Is a miss on the instruction cache as costly as on data cache? Probably. > It appears that in some places I am approaching and even passing 50% miss > rate > on the data cache reads. This sounds pretty bad. Yes, that's very bad. > What does "improve locality of accesses to them" mean in regards to the > crucial > data structure? Google for "locality". Basically, you want your memory accesses to be clustered close together as much as possible. If you're randomly jumping all over memory that will be bad for cache performance. Nick |
|
From: <val...@ce...> - 2006-03-09 22:14:38
|
[Ooops... I think the first time I responded to this the email went directly to Nick... sorry] Thanks for the info. I can now see where my cache misses are occurring most. I have a couple of more questions: Is a miss on the instruction cache as costly as on data cache? It appears that in some places I am approaching and even passing 50% miss rate on the data cache reads. This sounds pretty bad. What does "improve locality of accesses to them" mean in regards to the crucial data structure? Thanks, E Quoting Nicholas Nethercote <nj...@cs...>: > On Wed, 8 Mar 2006 val...@ce... wrote: > >> I am starting to use Valgrinds cachegrind to test my program for caches >> performance. Once i do this, how can I improve the cache performance? that >> is, how can I eliminate or reduce cache missies in my app? Are >> certain types >> of programming techniques more prone to cache misses? For example, nested >> loops? Certain data type declarations etc? Is there a good source of >> information on the internet? > > There is no easy answer. Cachegrind points you in the right > direction, but it can't tell you how directly how to fix your > program. There is lots of information about caches on the internet, > google for some. In general, try to make the crucial data structures > smaller, and improve locality of accesses to them. > > Nick > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Olly B. <ol...@su...> - 2006-03-09 21:48:57
|
On 2006-03-09, laurent de Vito <l_d...@ho...> wrote: > Is it a known limit of valgrind or should I set other Valgrind options > to allow the detection of such issues ? Known limitation: http://valgrind.org/docs/manual/faq.html#faq.overruns Cheers, Olly |
|
From: laurent de V. <l_d...@ho...> - 2006-03-09 21:38:05
|
Hallo,
I use a Suse Linux 9.3, AMD Duron (32 bits), gcc 3.3.5.
The following (reduced) piece of code
#include <stdarg.h>
#include <stdio.h>
void process_error(int num_args, ...)
{
char errors[1][1];
va_list ap;
va_start(ap,num_args);
sprintf( errors[0], "%s", va_arg(ap, char*));
}
int main()
{
process_error( 1, "blablabla");
return 0;
}
leads to a seg fault (because error is not big enough).
Valgrind does not in this case say something usefull
(
==29811== Jump to the invalid address stated on the next line
==29811== at 0x616C6261: ???
).
I tested Valgrind 3.2 and the latest version (revision 1594).
Valgrind output is identical.
Is it a known limit of valgrind or should I set other Valgrind options
to allow the detection of such issues ?
big thanks for the help.
Laurent
Valgrind output/
==29811== Memcheck, a memory error detector.
==29811== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==29811== Using LibVEX rev 1594, a library for dynamic binary translation.
==29811== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==29811== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation
framework.
==29811== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==29811==
==29811== My PID = 29811, parent PID = 7449. Prog and args are:
==29811== ./linux.open
==29811==
--29811--
--29811-- Command line
--29811-- ./linux.open
--29811-- Startup, with flags:
--29811-- --tool=memcheck
--29811-- -v
--29811-- --log-file=log
--29811-- Contents of /proc/version:
--29811-- Linux version 2.6.11.4-21.11-default (geeko@buildhost) (gcc
version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 Thu Feb 2 20:54:26 UTC
2006
--29811-- Arch and hwcaps: X86, x86-sse1
--29811-- Valgrind library directory: /usr/lib/valgrind
--29811-- Reading syms from /lib/ld-2.3.4.so (0x4000000)
--29811-- Reading syms from /home/laurent/gmc_bug/linux/linux.open
(0x8048000)
--29811-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck
(0xB0000000)
--29811-- object doesn't have a dynamic symbol table
--29811-- Reading suppressions file: /usr/lib/valgrind/default.supp
--29811-- REDIR: 0x4012B60 (index) redirected to 0xB001FB06
(vgPlain_x86_linux_REDIR_FOR_index)
--29811-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so
(0x4018000)
--29811-- Reading syms from
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x401B000)
==29811== WARNING: new redirection conflicts with existing -- ignoring it
--29811-- new: 0x04012B60 (index ) R-> 0x0401D6F0 index
--29811-- REDIR: 0x4012D00 (strlen) redirected to 0x401D980 (strlen)
--29811-- Reading syms from /lib/tls/libc.so.6 (0x4020000)
--29811-- REDIR: 0x4087C90 (rindex) redirected to 0x401D5D0 (rindex)
--29811-- REDIR: 0x40878D0 (strlen) redirected to 0x401D960 (strlen)
==29811== Jump to the invalid address stated on the next line
==29811== at 0x616C6261: ???
==29811== Address 0x616C6261 is not stack'd, malloc'd or (recently) free'd
==29811==
==29811== Process terminating with default action of signal 11 (SIGSEGV)
==29811== Access not within mapped region at address 0x616C6261
==29811== at 0x616C6261: ???
--29811-- REDIR: 0x40007A0 (_dl_sysinfo_int80) redirected to 0xB001FB03
(???)
--29811-- REDIR: 0x4082640 (free) redirected to 0x401C9A1 (free)
==29811==
==29811== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1)
==29811==
==29811== 1 errors in context 1 of 1:
==29811== Jump to the invalid address stated on the next line
==29811== at 0x616C6261: ???
==29811== Address 0x616C6261 is not stack'd, malloc'd or (recently) free'd
--29811--
--29811-- supp: 11 Ubuntu-stripped-ld.so
==29811==
==29811== IN SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1)
==29811==
==29811== malloc/free: in use at exit: 0 bytes in 0 blocks.
==29811== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==29811==
==29811== All heap blocks were freed -- no leaks are possible.
--29811-- memcheck: sanity checks: 0 cheap, 1 expensive
--29811-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--29811-- memcheck: auxmaps: 0 searches, 0 comparisons
--29811-- memcheck: secondaries: 5 issued (320k, 0M)
--29811-- memcheck: secondaries: 18 accessible and distinguished (1152k,
1M)
--29811-- translate: fast SP updates identified: 1,287 ( 89.4%)
--29811-- translate: generic_known SP updates identified: 77 ( 5.3%)
--29811-- translate: generic_unknown SP updates identified: 74 ( 5.1%)
--29811-- tt/tc: 2,995 tt lookups requiring 3,012 probes
--29811-- tt/tc: 2,994 fast-cache updates, 3 flushes
--29811-- transtab: new 1,398 (30,810 -> 512,870; ratio 166:10) [0
scs]
--29811-- transtab: dumped 0 (0 -> ??)
--29811-- transtab: discarded 9 (207 -> ??)
--29811-- scheduler: 23,574 jumps (bb entries).
--29811-- scheduler: 0/1,667 major/minor sched events.
--29811-- sanity: 1 cheap, 1 expensive checks.
--29811-- exectx: 30,011 lists, 7 contexts (avg 0 per list)
--29811-- exectx: 12 searches, 5 full compares (416 per 1000)
--29811-- exectx: 0 cmp2, 26 cmp4, 0 cmpAll
|