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
(14) |
2
(4) |
3
(1) |
|
4
(5) |
5
(12) |
6
(3) |
7
(2) |
8
(3) |
9
(9) |
10
|
|
11
(4) |
12
(5) |
13
(5) |
14
(8) |
15
(10) |
16
(5) |
17
|
|
18
|
19
(2) |
20
(2) |
21
(3) |
22
(2) |
23
(9) |
24
(1) |
|
25
(3) |
26
(2) |
27
(6) |
28
(2) |
29
(6) |
30
(6) |
31
(3) |
|
From: Christoph B. <bar...@or...> - 2005-12-05 22:16:49
|
Hi, I've just got the following error with valgrind 3.1.0: ==01:02:38:32.373 2400== Warning: set address range perms: large range 268439552, a 1, v 1 ==01:02:50:00.615 2400== Warning: set address range perms: large range 268439552, a 0, v 0 --01:02:52:57.936 2400-- INTERNAL ERROR: Valgrind received a signal 7 (SIGBUS) - exiting --01:02:52:57.936 2400-- si_code=2; Faulting address: 0x4F4029EC; sp: 0x495A44610 valgrind: the 'impossible' happened: Killed by fatal signal ==01:02:52:57.936 2400== at 0x700C0FCD: disInstr_AMD64 (toIR.c:7954) ==01:02:52:57.936 2400== by 0x7008F238: bb_to_IR (bb_to_IR.c:187) ==01:02:52:57.936 2400== by 0x700688E5: LibVEX_Translate (vex_main.c:416) ==01:02:52:57.936 2400== by 0x7002354D: vgPlain_translate (libvex_basictypes.h:154) ==01:02:52:57.936 2400== by 0x70034759: handle_tt_miss (scheduler.c:596) ==01:02:52:57.936 2400== by 0x70034B81: vgPlain_scheduler (scheduler.c:717) ==01:02:52:57.936 2400== by 0x7004785E: thread_wrapper (syswrap-linux.c:86) ==01:02:52:57.936 2400== by 0x70047955: run_a_thread_NORETURN (syswrap-linux.c:119) ==01:02:52:57.936 2400== by 0x70047A86: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:206) ==01:02:52:57.936 2400== by 0x70050F2E: (within /usr/local/opt/x86_64-20050615/lib/valgrind/amd64-linux/memcheck) sched status: running_tid=3 What could be wrong, and how to avoid it? Christoph Bartochek |
|
From: Dennis L. <pla...@in...> - 2005-12-05 20:25:31
|
At 21:17 05.12.2005, Nicholas Nethercote wrote: >On Mon, 5 Dec 2005, Dennis Lubert wrote: > >>The reason why "memcheck ls" is much easier for me than "valgrind >>--tool=memcheck ls" is that Im currently working with some wearable >>hardware that uses a heavily reconfigured variant of the frogpad >>(http://www.onehandedkeyboard.com/imagesfolder/frogrightjpg.JPG) >>where - and = are not so easy to reach ;) > >Can't you just create an alias or a wrapper script? Thats what I tried to say with "Ok, I will then put some wrapperscripts to start it properly." But it seemed to me a general good idea to suggest it, since for me (knowing only a bit of valgrind) it seemed to be easily implemented. And as you know, most programmers are lazy and will like to not type "valgrind --tool=" ;) greets Dennis Carpe quod tibi datum est |
|
From: Nicholas N. <nj...@cs...> - 2005-12-05 20:17:50
|
On Mon, 5 Dec 2005, Dennis Lubert wrote: > The reason why "memcheck ls" is much easier for me than "valgrind > --tool=memcheck ls" is that Im currently working with some wearable > hardware that uses a heavily reconfigured variant of the frogpad > (http://www.onehandedkeyboard.com/imagesfolder/frogrightjpg.JPG) where - > and = are not so easy to reach ;) Can't you just create an alias or a wrapper script? Nick |
|
From: Dennis L. <pla...@in...> - 2005-12-05 20:13:02
|
At 20:47 05.12.2005, Julian Seward wrote: >Why? What problem does it solve? It seems to let me start "memcheck ls" with the memcheck binary. > > Dunno if its the right way though... > >No. It is important for the valgrind launcher to be involved, for >more than one reason. Ok, I will then put some wrapperscripts to start it properly. The reason why "memcheck ls" is much easier for me than "valgrind --tool=memcheck ls" is that Im currently working with some wearable hardware that uses a heavily reconfigured variant of the frogpad (http://www.onehandedkeyboard.com/imagesfolder/frogrightjpg.JPG) where - and = are not so easy to reach ;) Could the program maybe exec "valgrind --tool=<whatevertool>" ? greets Dennis Carpe quod tibi datum est |
|
From: Tom T. <Tom...@sa...> - 2005-12-05 20:09:56
|
Consider the test program "fe.c" below. If I do cc -g fe.c and then = valgrind --trace-children=3Dno a.out =3D=3D4014=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D4014=3D=3D at 0x40063D: main (fe.c:12) This is inside the child! Is that appropriate? What I am really trying to do is exec a set-user-id program. Currently = valgrind fails with EACCES but I prefer that it instead print a warning = and then just exec the program untraced (which is what "truss"-type = commands do). Thanks much for considering this, Tom Truscott |
|
From: Dennis L. <pla...@in...> - 2005-12-05 20:08:46
|
At 20:28 05.12.2005, Julian Seward wrote: >./autogen.sh ; configure ; cd docs ; make html-docs print-docs might do it. Thanx, looks like it did build all docs. Now I only have to convince rpm to include the files, since it does not seem to see it. But thats my problem, thanx for the quick answer. greets Dennis Carpe quod tibi datum est |
|
From: Julian S. <js...@ac...> - 2005-12-05 19:47:50
|
> I have simply commented out the check for this environment variable > beeing unset, Why? What problem does it solve? > Dunno if its the right way though... No. It is important for the valgrind launcher to be involved, for more than one reason. J |
|
From: Dennis L. <pla...@in...> - 2005-12-05 19:43:25
|
Hi, I noticed that the new tools all themselves include a main() function which just outputs: valgrind: You cannot run 'toolname' directly. valgrind: You should use $prefix/bin/valgrind. when it detects that the environment variable VALGRIND_LAUNCHER is not the correct one. Could one make it so that launching the "memcheck" program launches memcheck (so one can do "memcheck ls")? I have simply commented out the check for this environment variable beeing unset, and it seems to work ! Dunno if its the right way though... greets Dennis Carpe quod tibi datum est |
|
From: Julian S. <js...@ac...> - 2005-12-05 19:28:26
|
./autogen.sh ; configure ; cd docs ; make html-docs print-docs might do it. J On Monday 05 December 2005 19:15, Dennis Lubert wrote: > Hi, > > is it possible to somehow build the docs right after a configure ? Or > do I really need to first make dist and then use the docs from there? > I ask because I want to have a build process were I create a rpm > package for me from fresh checked out svn code, and making dist, then > use the generated tarball again for the rpm seems a bit too complex > than a "make docs" in the rpm for me... > > greets > > Dennis > > Carpe quod tibi datum est > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-12-05 19:21:57
|
On Mon, 5 Dec 2005, Dennis Lubert wrote: > is it possible to somehow build the docs right after a configure ? Or do I > really need to first make dist and then use the docs from there? I ask > because I want to have a build process were I create a rpm package for me > from fresh checked out svn code, and making dist, then use the generated > tarball again for the rpm seems a bit too complex than a "make docs" in the > rpm for me... There are a few specific targets in docs/Makefile.am, eg. "print-docs", "all-docs", "html-docs". Nick |
|
From: Dennis L. <pla...@in...> - 2005-12-05 19:13:08
|
Hi, is it possible to somehow build the docs right after a configure ? Or do I really need to first make dist and then use the docs from there? I ask because I want to have a build process were I create a rpm package for me from fresh checked out svn code, and making dist, then use the generated tarball again for the rpm seems a bit too complex than a "make docs" in the rpm for me... greets Dennis Carpe quod tibi datum est |
|
From: Mathieu M. <mma...@ny...> - 2005-12-05 07:27:49
|
Hello again, So I placed an already compiled executable here: http://www.creatis.insa-lyon.fr/~malaterre/StringDes/TestString-3.4 Could someone with a svn version of valgrind please tell me if he can also see the warning ? Thanks. If someone else can duplicate it, should I report this as a valgrind bug or g++-3.4 ? I tried the subversion of valgrind, configure like this: ./configure --prefix=/home/mathieu/local make make install /home/mathieu/local/bin/valgrind --help valgrind: failed to start tool 'memcheck' for plateform 'x86-linux': No such file or directory Thanks Mathieu Mathieu Malaterre wrote: > I am having a very bizarre problem using valgrind (any version) and a > small code compiled with g++-3.4 > > valgrind is reporting this, *only* when compiled with g++-3.4 (any other > version seems to be fine). > > ==30206== 1 errors in context 1 of 1: > ==30206== Conditional jump or move depends on uninitialised value(s) > ==30206== at 0x1B9A356E: std::string::~string() (in > /usr/lib/libstdc++.so.6.0.7) > ==30206== by 0x8048F2E: main (TestString.cxx:14) > > > Here is the full valgrind log: > http://www.creatis.insa-lyon.fr/~malaterre/StringDes/valgrind-3.0.log > > Code is here: > http://www.creatis.insa-lyon.fr/~malaterre/StringDes/ > > Could someone with a little time and lot more expertise than me could > have a look into it, the C++ code is extremely short. > > Thanks > Mathieu > Ps: I am still struggling to get valgrind-svn autogen.sh to work... > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Dario L. <la...@cs...> - 2005-12-04 16:46:14
|
Julian Seward wrote: > ppc32 support is not good in 3.0.1 (which you used), but in the > just-released 3.1.0, it is very much better. So download > 3.1.0 from www.valgrind.org, build, and try that. > > J 3.1 works, thanks! Bye, Dario. -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it dario_at_astec.ms |
|
From: Julian S. <js...@ac...> - 2005-12-04 15:31:47
|
ppc32 support is not good in 3.0.1 (which you used), but in the just-released 3.1.0, it is very much better. So download 3.1.0 from www.valgrind.org, build, and try that. J On Sunday 04 December 2005 15:01, Dario Laera wrote: > Hi all, > it's the first time I'm using valgrind, so maybe it's only my fault, > but I can't use memcheck with a program. > I'm running on a ppc32, gcc version 3.4.4 (Gentoo 3.4.4-r1, > ssp-3.4.4-1.0, pie-8.7.8), and I want to debug uMPS, a mips machine > emulator written in C++: you can download an unofficial version a bit > debugged and with autotools on http://gridacuc.web.cs.unibo.it/umps/. > I've compiled it with CXXFLAGS="-g -O0", as suggested by the guide, but > Valgrind don't like this program :( > I've attache the long output, all the errors refers to /lib/ld-2.3.5.so > and none to the code I want to debug, also the program doesn't start > with this final error: > > iselInt64Expr(ppc32): No such tag(8) > Mux0X(t79,t127,Or64(Mux0X(t73,t135,t127),1Sto64(CmpNEZ8(1Uto8(CmpNEZ32(And3 >2(t146,And32(Or32(t23,t146),0x1:I32)))))))) vex: the `impossible' happened: > iselInt64Expr(ppc32) > vex storage: P 96, T total 259764292 (7241286), T curr 100220 (3237) > [...] > > Using lackey tool, the program runs fine, but the result of valgrind is > no so interesting... > > ==2749== Counted 0 calls to _dl_runtime_resolve() > ==2749== > ==2749== Executed: > ==2749== BBs: 0 > ==2749== guest instrs: 0 > ==2749== UInstrs: 0 > ==2749== > ==2749== Jccs: > ==2749== total: 0 > ==2749== % taken: 0% > ==2749== > ==2749== Ratios: > ==2749== guest instrs : BB = 0 : 10 > ==2749== UInstrs : BB = 0 : 10 > ==2749== UInstrs : x86_instr = 0 : 10 > ==2749== > ==2749== Exit code: 0 > > Then, with addrcheck I obtain: > > Addrcheck is currently not working, because: > (a) it is not yet ready to handle the Vex IR and the use with 64-bit > platforms introduced in Valgrind 3.0.0 > > Sorry for the inconvenience. Let us know if this is a problem for you. > > But this should be known :P > > Again, trying the cache tool I get: > > Cachegrind: cg_main.c:486 (handleOneStatement): Assertion 'NULL == > *storeAddrExpr' failed. > ==2770== at 0x70018770: vgPlain_assert_fail (in > /usr/lib/valgrind/stage2) ==2770== by 0x7001876C: vgPlain_assert_fail > (in /usr/lib/valgrind/stage2) ==2770== by 0x7102E48C: ??? > ==2770== by 0x70075860: LibVEX_Translate (in /usr/lib/valgrind/stage2) > ==2770== by 0x7002A544: vgPlain_translate (in /usr/lib/valgrind/stage2) > ==2770== by 0x70045BD8: vgPlain_scheduler (in /usr/lib/valgrind/stage2) > ==2770== by 0x700695D8: vgModuleLocal_thread_wrapper (in > /usr/lib/valgrind/stage2) > ==2770== by 0x70065FAC: (within /usr/lib/valgrind/stage2) > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable > ==2770== at 0x25483154: memset (in /lib/ld-2.3.5.so) > ==2770== by 0x254773D0: _dl_map_object (in /lib/ld-2.3.5.so) > ==2770== by 0x25471DF4: map_doit (in /lib/ld-2.3.5.so) > ==2770== by 0x2547B630: _dl_catch_error (in /lib/ld-2.3.5.so) > ==2770== by 0x25471F28: do_preload (in /lib/ld-2.3.5.so) > ==2770== by 0x25474178: dl_main (in /lib/ld-2.3.5.so) > ==2770== by 0x2547F18C: _dl_sysdep_start (in /lib/ld-2.3.5.so) > ==2770== by 0x25472158: _dl_start_final (in /lib/ld-2.3.5.so) > ==2770== by 0x254725AC: _dl_start (in /lib/ld-2.3.5.so) > ==2770== by 0x25480458: _start (in /lib/ld-2.3.5.so) > > Just massif seems to work well, so I don't paste any output. > > Is it me wrong? Is it uMPS? Or... Valgrind? > > Thanks, > Dario. |
|
From: Dario L. <la...@cs...> - 2005-12-04 15:02:07
|
Hi all, it's the first time I'm using valgrind, so maybe it's only my fault, but I can't use memcheck with a program. I'm running on a ppc32, gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8), and I want to debug uMPS, a mips machine emulator written in C++: you can download an unofficial version a bit debugged and with autotools on http://gridacuc.web.cs.unibo.it/umps/. I've compiled it with CXXFLAGS="-g -O0", as suggested by the guide, but Valgrind don't like this program :( I've attache the long output, all the errors refers to /lib/ld-2.3.5.so and none to the code I want to debug, also the program doesn't start with this final error: iselInt64Expr(ppc32): No such tag(8) Mux0X(t79,t127,Or64(Mux0X(t73,t135,t127),1Sto64(CmpNEZ8(1Uto8(CmpNEZ32(And32(t146,And32(Or32(t23,t146),0x1:I32)))))))) vex: the `impossible' happened: iselInt64Expr(ppc32) vex storage: P 96, T total 259764292 (7241286), T curr 100220 (3237) [...] Using lackey tool, the program runs fine, but the result of valgrind is no so interesting... ==2749== Counted 0 calls to _dl_runtime_resolve() ==2749== ==2749== Executed: ==2749== BBs: 0 ==2749== guest instrs: 0 ==2749== UInstrs: 0 ==2749== ==2749== Jccs: ==2749== total: 0 ==2749== % taken: 0% ==2749== ==2749== Ratios: ==2749== guest instrs : BB = 0 : 10 ==2749== UInstrs : BB = 0 : 10 ==2749== UInstrs : x86_instr = 0 : 10 ==2749== ==2749== Exit code: 0 Then, with addrcheck I obtain: Addrcheck is currently not working, because: (a) it is not yet ready to handle the Vex IR and the use with 64-bit platforms introduced in Valgrind 3.0.0 Sorry for the inconvenience. Let us know if this is a problem for you. But this should be known :P Again, trying the cache tool I get: Cachegrind: cg_main.c:486 (handleOneStatement): Assertion 'NULL == *storeAddrExpr' failed. ==2770== at 0x70018770: vgPlain_assert_fail (in /usr/lib/valgrind/stage2) ==2770== by 0x7001876C: vgPlain_assert_fail (in /usr/lib/valgrind/stage2) ==2770== by 0x7102E48C: ??? ==2770== by 0x70075860: LibVEX_Translate (in /usr/lib/valgrind/stage2) ==2770== by 0x7002A544: vgPlain_translate (in /usr/lib/valgrind/stage2) ==2770== by 0x70045BD8: vgPlain_scheduler (in /usr/lib/valgrind/stage2) ==2770== by 0x700695D8: vgModuleLocal_thread_wrapper (in /usr/lib/valgrind/stage2) ==2770== by 0x70065FAC: (within /usr/lib/valgrind/stage2) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==2770== at 0x25483154: memset (in /lib/ld-2.3.5.so) ==2770== by 0x254773D0: _dl_map_object (in /lib/ld-2.3.5.so) ==2770== by 0x25471DF4: map_doit (in /lib/ld-2.3.5.so) ==2770== by 0x2547B630: _dl_catch_error (in /lib/ld-2.3.5.so) ==2770== by 0x25471F28: do_preload (in /lib/ld-2.3.5.so) ==2770== by 0x25474178: dl_main (in /lib/ld-2.3.5.so) ==2770== by 0x2547F18C: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==2770== by 0x25472158: _dl_start_final (in /lib/ld-2.3.5.so) ==2770== by 0x254725AC: _dl_start (in /lib/ld-2.3.5.so) ==2770== by 0x25480458: _start (in /lib/ld-2.3.5.so) Just massif seems to work well, so I don't paste any output. Is it me wrong? Is it uMPS? Or... Valgrind? Thanks, Dario. -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it dario_at_astec.ms |
|
From: Josef W. <Jos...@gm...> - 2005-12-04 09:16:51
|
On Thursday 01 December 2005 21:49, Bill Rugolsky Jr. wrote: > Sorry to reply to myself, but I got callgrind building in-tree Hi, nice to know this is possible... I still think that it is a valuable "exercise" to make external valgrind tools work. This way, I can do separate releases, and for minor valgrind releases, I do not have to do one, too. Josef |
|
From: Olly B. <ol...@su...> - 2005-12-04 02:50:47
|
On 2005-12-03, Stewart, Hugh <hu...@ug...> wrote: > At this point it died because I didn't have write access to /usr/local > so I tried > > ./configure --prefix=<somewhere> > make > make install This is a standard autoconf thing. You need to start from a clean source tree (which you can get with "make distclean") before you can safely rerun configure with different options: http://sources.redhat.com/ml/autoconf/1999-09/msg00154.html Cheers, Olly |
|
From: Stewart, H. <hu...@ug...> - 2005-12-03 13:57:15
|
I downloaded and set about installing valgrind (3.1.0) and blindy went ./configure make make install At this point it died because I didn't have write access to /usr/local so I tried ./configure --prefix=3D<somewhere> make make install but valgrind failed because VG_LIBDIR was still defined to /usr/local. make clean make make install worked. P.S. the FAQ told me to give you the output of valgrind -v so since you insist, here it is :-) valgrind: no program specified valgrind: Use --help for more information. PPS, now I'm actually getting into it... I'm suppressing my way through some external library (the documentation doesn't say you can suppress by library with obj:). It would be nice if the print suppressions would automatically apply the suppression it has just printed so I don't have to decide whether this strange traceback is a duplicate or just a minor variation of=20 one I've already copied into my suppressions file |
|
From: Josef W. <Jos...@gm...> - 2005-12-02 20:31:31
|
On Thursday 01 December 2005 16:48, Bill Rugolsky Jr. wrote:
> Does anyone have a patch to get Callgrind-0.10.1 to build both x86
> and amd64 versions of tools, either in or out of the Valgrind tree?
> I'm trying to package the bi-arch support in an FC4 RPM.
>
> I've started hacking the {.am,in} input, but GNU Autotools makes my
> brain hurt. :-/
If you can fake a valgrind.pc for 32bit, it could work.
I do not know if valgrind 3.1 can be forced to compile in 32bit only
on AMD64.
Josef
|
|
From: Michael R. <mr...@wi...> - 2005-12-02 16:36:56
|
> > >--__--__-- > >Message: 11 >To: val...@li... >Subject: Re: [Valgrind-users] EINTR on socket calls on Linux RHEL3 >From: Tom Hughes <to...@co...> >Organization: Just Me >Date: Thu, 01 Dec 2005 16:18:14 +0000 > >In message <a06100545bfb4cc256a9d@[10.100.2.144]> > Michael Rutman <mr...@wi...> wrote: > >> At 7:47 AM -0800 12/1/05, Duncan Sands wrote: >>> >>>> I'm not sure why an EINTR is being issued. The call to socket shouldn't >>>> ever be returning that according to the man page. >>> >>>Is it the kernel or libc that generates the EINTR? >>> >> >> Sorry for wasting everyone's time. I was using the valgrind installed on >> RHEL 3. > >Oh right. I was kind of assuming we were talking valgrind 3 at least. > >> I pulled the sources for valgrind 2.4.1 to see if it was throwing the >> exception and it works fine. >> >> So, the lesson is, don't use the installed one but always grab the latest >> sources. > >Which 2.4.1 isn't... > >Tom > >-- >Tom Hughes (to...@co...) ><http://www.compton.nu/>http://www.compton.nu/ > > >--__--__-- > >Message: 12 >From: Julian Seward <js...@ac...> >To: val...@li... >Subject: Re: [Valgrind-users] EINTR on socket calls on Linux RHEL3 >Date: Thu, 1 Dec 2005 16:51:34 +0000 > > >> > So, the lesson is, don't use the installed one but always grab the latest >> > sources. >> >> Which 2.4.1 isn't... > >Not even slightly. Michael, try 3.1.0 and let us know what happens. > >J > 3.1.0 works fine too. It appears to just be a problem on the RHEL 3 distribution version. Many thanks for the help. |
|
From: Mads K. <kii...@gm...> - 2005-12-02 15:25:26
|
SGksCgpPbiAxMi8yLzA1LCBDaHJpc3RvcGggQmFydG9zY2hlayA8YmFydG9zY2hla0Bvci51bmkt Ym9ubi5kZT4gd3JvdGU6Cj4gaG93IGNhbiBJIGVuY29kZSBhIHN1cHByZXNzaW9uIHdoaWNoIGRp c2FibGVzIGFsbCB3YXJuaW5ncyBmcm9tIGZ1bmN0aW9ucwo+IHdoaWNoIGxpZSBiZWxvdyBhIHNw ZWNpZmljIGZ1bmN0aW9uPwouLi4KPiBOb3cgSSBoYXZlIGEgbG90IG9mIG90aGVyIHN1cHByZXNz aW9ucyB3aGljaCBhbGwgYXJlIGNoaWxkcmVuIG9mIHRoZSBmdW5jdGlvbgo+ICJyb290X29mX2Fs bF9ldmlsIi4gIEhvdyBjYW4gSSBkaXNhYmxlIGFsbCB3YXJuaW5ncyB3aXRoIG9ubHkgb25lIGVu dHJ5IGluCj4gdGhlIHN1cHByZXNzaW9ucyBmaWxlPwoKRm9yIHRoZSB2ZXJ5IHNhbWUgcmVhc29u cyBJIGhhdmUgbWFkZSB0aGUgY2hhbmdlcyBiZWxvdy4gVGhleSBhcmUgbm90CmNvbXBsZXRlbHkg ZmluaXNoZWQgYW5kIG5vdCBwb2xpc2hlZCwgYnV0IHRoZXkgd29ya3MgKG9yIGhhdmUgd29ya2Vk KQpmb3IgbWUuLi4KClRoZSBjaGFuZ2VzIHJlc3RydWN0dXJlcyBzdXBwX21hdGNoZXNfY2FsbGVy cyAtIGFuZCBJTUhPIG1ha2VzIGl0CmVhc2llciB0byBncmFzcC4KCklJUkMgdGhlIGV4aXN0aW5n IGFsZ29yaXRobSBpcyBPKHN1cHByZXNzaW9ucyoiNCIpLCBidXQgbXkgY2hhbmdlcwptYWtlcyBp dCBPKHN1cHByZXNzaW9ucyooc3VwcHJlc2lvbmxlbmd0aCtzdGFja3RyYWNlbGVuZ3RoKSkuIEl0 CnNob3VsZCBiZSBwb3NzaWJsZSB0byBmYWxsIGJhY2sgdG8gbm90IHNlYXJjaCB0aHJvdWdoIHRo ZSBzdGFja3RyYWNlCmZvciBtYXRjaGluZyBzdXBwcmVzc2lvbnMgLSB0aGF0IHNob3VsZCBiZSBj b250cm9sbGVkIGJ5IGFuIG9wdGlvbi4gT3IKcGVyaGFwcyBvbmx5IGJlIGVuYWJsZWQgZm9yIHN1 cHByZXNzaW9ucyB3aXRoIGEgc3BlY2lhbCB0YWcuCgpUaGVyZSBtaWdodCBhbHNvIGJlIHNvbWUg aXNzdWVzIHdpdGggdGhlIG1hZ2ljICI0Ii4KCi9NYWRzCgoKLS0tIGNvcmVncmluZC9tX2Vycm9y bWdyLmMJKHJldmlzaW9uIDQ5NjcpCisrKyBjb3JlZ3JpbmQvbV9lcnJvcm1nci5jCSh3b3JraW5n IGNvcHkpCkBAIC0xMDg1LDM1ICsxMDg1LDQ2IEBACiBzdGF0aWMKIEJvb2wgc3VwcF9tYXRjaGVz X2NhbGxlcnMoRXJyb3IqIGVyciwgU3VwcCogc3UpCiB7Ci0gICBJbnQgaTsKKyAgIEludCBpLHRy YWNlb2Zmc2V0OwogICAgQ2hhciBjYWxsZXJfbmFtZVtFUlJUWFRfTEVOXTsKICAgIFN0YWNrVHJh Y2UgaXBzID0gVkdfKGV4dHJhY3RfU3RhY2tUcmFjZSkoZXJyLT53aGVyZSk7Ci0KLSAgIGZvciAo aSA9IDA7IGkgPCBzdS0+bl9jYWxsZXJzOyBpKyspIHsKLSAgICAgIEFkZHIgYSA9IGlwc1tpXTsK KworICAgZm9yIChpID0gMCwgdHJhY2VvZmZzZXQgPSAwOyBpIDwgc3UtPm5fY2FsbGVyczsgKSB7 CiAgICAgICB2Z19hc3NlcnQoc3UtPmNhbGxlcnNbaV0ubmFtZSAhPSBOVUxMKTsKLSAgICAgIC8v IFRoZSBzdHJpbmcgdG8gYmUgdXNlZCBpbiB0aGUgdW5rbm93biBjYXNlICgiPz8/IikgY2FuIGJl IGFueXRoaW5nCi0gICAgICAvLyB0aGF0IGNvdWxkbid0IGJlIGEgdmFsaWQgZnVuY3Rpb24gb3Ig b2JqbmFtZS4gIC0tZ2VuLXN1cHByZXNzaW9ucwotICAgICAgLy8gcHJpbnRzICdvYmo6KicgZm9y IHN1Y2ggYW4gZW50cnksIHdoaWNoIHdpbGwgbWF0Y2ggYW55IHN0cmluZyB3ZQotICAgICAgLy8g dXNlLgotICAgICAgc3dpdGNoIChzdS0+Y2FsbGVyc1tpXS50eSkgewotICAgICAgICAgY2FzZSBP YmpOYW1lOgotICAgICAgICAgICAgaWYgKCFWR18oZ2V0X29iam5hbWUpKGEsIGNhbGxlcl9uYW1l LCBFUlJUWFRfTEVOKSkKLSAgICAgICAgICAgICAgIFZHXyhzdHJjcHkpKGNhbGxlcl9uYW1lLCAi Pz8/Iik7Ci0gICAgICAgICAgICBicmVhazsKKyAgICAgIGRvIHsgLy8gSW5jcmVhc2UgdHJhY2Vv ZmZzZXQgdW50aWwgZmlyc3Qgc3VwcHJlc3Npb24gbWF0Y2hlZAorICAgICAgICAgQWRkciBhID0g aXBzW2krdHJhY2VvZmZzZXRdOworICAgICAgICAgaWYgKGE9PTApIHsKKyAgICAgICAgICAgIHJl dHVybiBGYWxzZTsgLy8gZW5kIG9mIGVycm9yIHRyYWNlIHJlYWNoZWQgYnV0CnN1cHByZXNzaW9u cyByZW1haW5zCisgICAgICAgICB9CisgICAgICAgICAvLyBUaGUgc3RyaW5nIHRvIGJlIHVzZWQg aW4gdGhlIHVua25vd24gY2FzZSAoIj8/PyIpIGNhbiBiZSBhbnl0aGluZworICAgICAgICAgLy8g dGhhdCBjb3VsZG4ndCBiZSBhIHZhbGlkIGZ1bmN0aW9uIG9yIG9iam5hbWUuICAtLWdlbi1zdXBw cmVzc2lvbnMKKyAgICAgICAgIC8vIHByaW50cyAnb2JqOionIGZvciBzdWNoIGFuIGVudHJ5LCB3 aGljaCB3aWxsIG1hdGNoIGFueSBzdHJpbmcgd2UKKyAgICAgICAgIC8vIHVzZS4KKyAgICAgICAg IHN3aXRjaCAoc3UtPmNhbGxlcnNbaV0udHkpIHsKKyAgICAgICAgICAgIGNhc2UgT2JqTmFtZToK KyAgICAgICAgICAgICAgIGlmICghVkdfKGdldF9vYmpuYW1lKShhLCBjYWxsZXJfbmFtZSwgRVJS VFhUX0xFTikpCisgICAgICAgICAgICAgICAgICBWR18oc3RyY3B5KShjYWxsZXJfbmFtZSwgIj8/ PyIpOworICAgICAgICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgICAgIGNhc2UgRnVuTmFtZToK KyAgICAgICAgICAgICAgIC8vIE5iOiBtYW5nbGVkIG5hbWVzIHVzZWQgaW4gc3VwcHJlc3Npb25z CisgICAgICAgICAgICAgICBpZiAoIVZHXyhnZXRfZm5uYW1lX25vZGVtYW5nbGUpKGEsIGNhbGxl cl9uYW1lLCBFUlJUWFRfTEVOKSkKKyAgICAgICAgICAgICAgICAgIFZHXyhzdHJjcHkpKGNhbGxl cl9uYW1lLCAiPz8/Iik7CisgICAgICAgICAgICAgICBicmVhazsKCi0gICAgICAgICBjYXNlIEZ1 bk5hbWU6Ci0gICAgICAgICAgICAvLyBOYjogbWFuZ2xlZCBuYW1lcyB1c2VkIGluIHN1cHByZXNz aW9ucwotICAgICAgICAgICAgaWYgKCFWR18oZ2V0X2ZubmFtZV9ub2RlbWFuZ2xlKShhLCBjYWxs ZXJfbmFtZSwgRVJSVFhUX0xFTikpCi0gICAgICAgICAgICAgICBWR18oc3RyY3B5KShjYWxsZXJf bmFtZSwgIj8/PyIpOwotICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgICBkZWZhdWx0OiBWR18o dG9vbF9wYW5pYykoInN1cHBfbWF0Y2hlc19jYWxsZXJzIik7Ci0gICAgICB9Ci0gICAgICBpZiAo IVZHXyhzdHJpbmdfbWF0Y2gpKHN1LT5jYWxsZXJzW2ldLm5hbWUsIGNhbGxlcl9uYW1lKSkKLSAg ICAgICAgIHJldHVybiBGYWxzZTsKKyAgICAgICAgICAgIGRlZmF1bHQ6IFZHXyh0b29sX3Bhbmlj KSgic3VwcF9tYXRjaGVzX2NhbGxlcnMiKTsKKyAgICAgICAgIH0KKyAgICAgICAgIGlmIChWR18o c3RyaW5nX21hdGNoKShzdS0+Y2FsbGVyc1tpXS5uYW1lLCBjYWxsZXJfbmFtZSkpIHsKKyAgICAg ICAgICAgIGkrKzsgLy8gbWF0Y2ggZm91bmQsIGNoZWNrIG5leHQgLSBhbmQgdHJhY2VvZmZzZXQg aXMgbm93IGxvY2tlZAorICAgICAgICAgfSBlbHNlIGlmIChpPT0wKSB7IC8vIHRyYWNlb2Zmc2V0 IG5vdCBsb2NrZWQKKyAgICAgICAgICAgIHRyYWNlb2Zmc2V0Kys7IC8vIHRyeSBuZXh0IG9mZnNl dAorICAgICAgICAgfSBlbHNlIHsgLy8gdHJhY2VvZmZzZXQgbG9ja2VkLCBubyBtYXRjaCwgYmFk IGx1Y2sKKyAgICAgICAgICAgIHJldHVybiBGYWxzZTsKKyAgICAgICAgIH0KKyAgICAgIH0gd2hp bGUgKGk9PTApOyAvLyBsb29wIHdoaWxlIHRyYWNlb2Zmc2V0IG5vdCBsb2NrZWQKICAgIH0KLQot ICAgLyogSWYgd2UgcmVhY2ggaGVyZSwgaXQncyBhIG1hdGNoICovCisKKyAgIC8qIE9rOyBhbGwg aT1zdS0+bl9jYWxsZXJzIG1hdGNoZWQgYXQgZXJyb3JbdHJhY2VvZmZzZXRdICovCiAgICByZXR1 cm4gVHJ1ZTsKIH0K |
|
From: Christoph B. <bar...@or...> - 2005-12-02 14:36:31
|
Hello,
how can I encode a suppression which disables all warnings from functions
which lie below a specific function?
For example I have the following suppressions:
{
A
Memcheck:Overlap
fun:strcpy
fun:D
fun:C
fun:B
fun:A
fun:root_of_all_evil
}
{
B
Memcheck:Overlap
fun:strcpy
fun:B
fun:A
fun:root_of_all_evil
}
Now I have a lot of other suppressions which all are children of the function
"root_of_all_evil". How can I disable all warnings with only one entry in
the suppressions file?
Christoph Bartoschek
|
|
From: Bill R. Jr. <bru...@te...> - 2005-12-01 20:50:14
|
On Thu, Dec 01, 2005 at 10:48:56AM -0500, Bill Rugolsky Jr. wrote:
> Does anyone have a patch to get Callgrind-0.10.1 to build both x86
> and amd64 versions of tools, either in or out of the Valgrind tree?
> I'm trying to package the bi-arch support in an FC4 RPM.
>
> I've started hacking the {.am,in} input, but GNU Autotools makes my
> brain hurt. :-/
Sorry to reply to myself, but I got callgrind building in-tree
on FC4-x86_64 using some nasty hacks to untar callgrind, move a
bunch of files around, apply a patch, and run the Autotools.
[S]RPMS can be found on my home machine:
ftp://67.83.200.158/pub/valgrind/
13435 Dec 01 20:19 valgrind-3.1.0-0.ti.2.fc4.nosrc.rpm
3242181 Dec 01 20:19 valgrind-3.1.0-0.ti.2.fc4.src.rpm
24610498 Dec 01 20:19 valgrind-3.1.0-0.ti.2.fc4.x86_64.rpm
480967 Dec 01 20:19 valgrind.build.out
The .spec file and patch are attached. Perhaps someone will find this useful.
Regards,
Bill Rugolsky
|
|
From: Tom H. <to...@co...> - 2005-12-01 17:11:31
|
In message <200...@ti...>
Bill Rugolsky, Jr. <bru...@te...> wrote:
> Does anyone have a patch to get Callgrind-0.10.1 to build both x86
> and amd64 versions of tools, either in or out of the Valgrind tree?
> I'm trying to package the bi-arch support in an FC4 RPM.
No, because it relies on pkgconfig and we haven't sorted the pkgconfig
stuff in valgrind to be biarch aware yet.
> I've started hacking the {.am,in} input, but GNU Autotools makes my
> brain hurt. :-/
I have up and made callgrind 64 bit only in my RPMs for now.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-12-01 16:51:50
|
> > So, the lesson is, don't use the installed one but always grab the latest > > sources. > > Which 2.4.1 isn't... Not even slightly. Michael, try 3.1.0 and let us know what happens. J |