You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Eyal L. <ey...@ey...> - 2004-01-07 23:18:55
|
I found what is causing the problem. I run a program which execvp()s a shell which runs the original program. My shell runs the program as 'valgrind ... ssasrsv', meaning that valgrind is memchecking itself. Attached is a program that demonstrates the problem. It used to be OK until 2.0.0 but is failing since 2.1.0. I now changed my scripts to never recurse into valgrind (I never really needed or wanted to do so). Still, something changed which needs a looking into. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Josef W. <Jos...@gm...> - 2004-01-07 22:40:22
|
Am Mittwoch, 7. Januar 2004 12:02 schrieb Tom Hughes: > In message <200...@gm...> > > BTW, this doesn't allow column chars in any option any more, right? > column chars? Oops, I meant ":" (colon). Josef |
|
From: Dirk M. <mu...@kd...> - 2004-01-07 19:19:31
|
CVS commit by mueller:
rsqrtss support (backport)
M +9 -0 vg_to_ucode.c 1.87.2.17
--- valgrind/coregrind/vg_to_ucode.c #1.87.2.16:1.87.2.17
@@ -4791,4 +4791,13 @@ static Addr disInstr ( UCodeBlock* cb, A
}
+ /* RSQRTSS: square root reciprocal of scalar float. */
+ if (insn[0] == 0xF3 && insn[1] == 0x0F && insn[2] == 0x52) {
+ vg_assert(sz == 4);
+ eip = dis_SSE3_reg_or_mem ( cb, sorb, eip+3, 4,
+ "sqrtss",
+ insn[0], insn[1], insn[2] );
+ goto decode_success;
+ }
+
/* MOVLPS -- 8-byte load/store. How is this different from MOVLPS
? */
|
|
From: Dirk M. <mu...@kd...> - 2004-01-07 19:13:41
|
CVS commit by mueller:
yet another SSE insn (rsqrtss)
M +9 -0 vg_to_ucode.c 1.121
--- valgrind/coregrind/vg_to_ucode.c #1.120:1.121
@@ -4514,4 +4514,13 @@ static Addr disInstr ( UCodeBlock* cb, A
}
+ /* RSQRTSS: square root reciprocal of scalar float. */
+ if (insn[0] == 0xF3 && insn[1] == 0x0F && insn[2] == 0x52) {
+ vg_assert(sz == 4);
+ eip = dis_SSE3_reg_or_mem ( cb, sorb, eip+3, 4,
+ "sqrtss",
+ insn[0], insn[1], insn[2] );
+ goto decode_success;
+ }
+
/* MOVLPS -- 8-byte load/store. How is this different from MOVLPS
? */
|
|
From: Ayodele T. <em...@st...> - 2004-01-07 17:48:43
|
I tried running the same skin twice on the same executable (with no changes), and even that gave different results for the data memory addresses. I will have to figure out another way to reduce my memory requirements - maybe dumping state to a file occasionally and then only reading it back when needed. Ayo > > On Wed, 7 Jan 2004, Ayodele Thomas wrote: > > > My initial step is designed to identify data addresses that are read only > > so that they can be excluded from the main analysis performed by the > > second step. Therefore, the second step is the critical step and must be > > performed in Valgrind. I can't think of a way that both steps can be > > performed at the same time because the goal is to determine which data can > > be ignored - but that cannot be determined until the entire application > > has run because I am locating dependencies. > > So you can't tell which addresses are read only until the program has > finished? Ok, I think I understand. > > > The initial step is designed to reduce the memory requirements because I must > > keep track of a tremendous amount of state in the main pass and have > > issues running out of memory and crashing, even with the 2GB of memory on > > my machine. > > What about if you put both passes into the same skin, and then switch > between the pre-processing and main processing with a command-line arg? > That way, you will hopefully get the same memory addresses for both runs. > However, even if it does work, it sounds fragile. > > N > -- --------------------------------------------------------------- Ayodele Bolaji Thomas "Joy in the Morning" Ph.D. Candidate Electrical Engineering Computer Systems Laboratory Stanford University Ayo...@st... Support our troops. Support our country. Pray for Peace. \o/ "We succeed, not because of Affirmative Action, but in spite of the conditions that make it necessary" (ABE '98) "War may sometimes be a necessary evil. But no matter how necessary, it is always an evil, never a good. We will not learn to live together in peace by killing each other's children." Jimmy Carter '02 --------------------------------------------------------------- |
|
From: Nicholas N. <nj...@ca...> - 2004-01-07 16:51:30
|
On Wed, 7 Jan 2004, Ayodele Thomas wrote: > My initial step is designed to identify data addresses that are read only > so that they can be excluded from the main analysis performed by the > second step. Therefore, the second step is the critical step and must be > performed in Valgrind. I can't think of a way that both steps can be > performed at the same time because the goal is to determine which data can > be ignored - but that cannot be determined until the entire application > has run because I am locating dependencies. So you can't tell which addresses are read only until the program has finished? Ok, I think I understand. > The initial step is designed to reduce the memory requirements because I must > keep track of a tremendous amount of state in the main pass and have > issues running out of memory and crashing, even with the 2GB of memory on > my machine. What about if you put both passes into the same skin, and then switch between the pre-processing and main processing with a command-line arg? That way, you will hopefully get the same memory addresses for both runs. However, even if it does work, it sounds fragile. N |
|
From: Ayodele T. <em...@st...> - 2004-01-07 16:43:58
|
My initial step is designed to identify data addresses that are read only so that they can be excluded from the main analysis performed by the second step. Therefore, the second step is the critical step and must be performed in Valgrind. I can't think of a way that both steps can be performed at the same time because the goal is to determine which data can be ignored - but that cannot be determined until the entire application has run because I am locating dependencies. The initial step is designed to reduce the memory requirements because I must keep track of a tremendous amount of state in the main pass and have issues running out of memory and crashing, even with the 2GB of memory on my machine. Ayodele > > On Tue, 6 Jan 2004, Ayodele Thomas wrote: > > > Because of the memory requirements of my skin, I would like to do a > > preprocessing step where I look at all of the data addresses produced and > > dump a file containing addresses that are read only. Then I > > want to read those addresses in and use them. Currently, I > > have one skin that does the preprocessing and another than does > > the main processing. > > Does the second step have to be done as a Valgrind skin -- could it be > done with a standalone program? Or, can you do the pre-processing and the > main processing at the same time? That seems a better way to do things. > > > However, when I re-execute the code with the > > different skin, the memory addresses move and they no longer match up. > > I think this is because the different skins have different sizes and thus > cause memory to be laid out in a different way. When developing > Cachegrind, I found that the hit/miss counts would change slightly > whenever I made the slightest change to the skin code, for exactly this > reason. > > > Is there a way to force the application to run a second time within the > > same skin? (i.e. make two passes). I think then the addresses would be > > stable between the two runs. > > Not that I'm aware of. > > N > -- --------------------------------------------------------------- Ayodele Bolaji Thomas "Joy in the Morning" Ph.D. Candidate Electrical Engineering Computer Systems Laboratory Stanford University Ayo...@st... Support our troops. Support our country. Pray for Peace. \o/ "We succeed, not because of Affirmative Action, but in spite of the conditions that make it necessary" (ABE '98) "War may sometimes be a necessary evil. But no matter how necessary, it is always an evil, never a good. We will not learn to live together in peace by killing each other's children." Jimmy Carter '02 --------------------------------------------------------------- |
|
From: Eyal L. <ey...@ey...> - 2004-01-07 14:30:58
|
Jeremy Fitzhardinge wrote: > > On Sat, 2004-01-03 at 17:57, Eyal Lebedinsky wrote: > > Jeremy Fitzhardinge wrote: > > > Um. It would be nice if you could give us a lot more detail - like the > > > actual error message it generated, and other debugging stuff it probably > > > printed. And what do you mean by "spawn"? There's no library function > > > or syscall called that. Do you mean system? execve? > > > > OK, I now have these logs. First a good run of a program 'ssaexec' which > > simply spawn a child with the same arguments as itself. In real life it > > is > > used as a wrapper for redirecting stdout/err and such. > > OK, sync to CVS and try again. I just fixed a bug which would cause > child Valgrinds to die with a SEGV. (Though it would have only affected > CVS HEAD; 2.1.0 should have been OK.) As said before, while the sample program works now, my program still segfaults. I should explain how it works. To run valgrind with debugging each program (e.g. 'ssasrsv') is renamed to ssasrsv.orig and a shell script called 'ssasrsv' is put in its place, which does some setup and then runs 'ssasrsv.orig'. To get a clean run, when 'ssasrsv.orig' is about to be execvp()ed, the '.orig' suffix is removed thus execing the shell wrapper. OK, so in the following log you will see the execv() stage, which should start the shell wrapper (which will emit the 'start:' and 'cmd:' lines) which will then run 'ssasrsv'. I hope someone will figure what is going on. First, the '=no' case. We see 27843, which is the forked child, execing the shell, which then runs the real child (27849) which dumps the env as main() is entered. It looks right. ssasrsv [27843/1]> exec.c(294) ssaio_exec: CALL execvp [27843] start: Thu Jan 8 00:45:25 EST 2004 [27843] cmd: /ssa/builds/20031229-vgi/bin/ssasrsv -n3050 -m3052 -vus -1/ssa/builds/20031229-vgi/ids/idssrsv.log -2/ss a/builds/20031229-vgi/ids/idssrsv.err -3/ssa/builds/20031229-vgi/ids/ids.dbg -f356004891 --27849-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --27849-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --27849-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --27849-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --27849-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --27849-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --27849-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --27849-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==27849== Time: 2004/01/08 00:45:25 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:25 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:25 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:27 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==27849== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==27849== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==27849== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:27 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==27849== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==27849== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==27849== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) pid=27849 env[1]='PWD=/ssa/builds/20031229-vgi/ids' env[2]='SSANAME=/ssa/builds/20031229-vgn/ssaname' env[3]='SSACCID=GCCLIBC2' env[4]='SSAWORKDIR=/ssa/builds/20031229-vgi/ids' Now the same story with '=yes' looks very different. The forked child (28103) seems to actually sleep while the main program continues for a while (pid 28114 and 28121 which are probably 'basename' and 'date' in the shell). Finally the shell runs ssasrsv (pid 28128) which crashed right away. ssasrsv [28103/1]> exec.c(294) ssaio_exec: CALL execvp --28103-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28103-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28103-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28103-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28103-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28103-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28103-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28103-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28103== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28103== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28103== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28103== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28103== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28103== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) --28114-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28114-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28114-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28114-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28114-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28114-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28114-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28114-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28114== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28114== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28114== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28114== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28114== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28114== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) --28121-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28121-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28121-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28121-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28121-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28121-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28121-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28121-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28121== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28121== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28121== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28121== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28121== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28121== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) [28103] start: Thu Jan 8 00:46:16 EST 2004 [28103] cmd: /ssa/builds/20031229-vgi/bin/ssasrsv -n3050 -m3052 -vus -1/ssa/builds/20031229-vgi/ids/idssr sv.log -2/ssa/builds/20031229-vgi/ids/idssrsv.err -3/ssa/builds/20031229-vgi/ids/ids.dbg -f355182354 --28128-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28128-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28128-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28128-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28128-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28128-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28128-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28128-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF Executable is mapped outside of range 0x80c9000-0x4fffd000 failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory --28135-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28135-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28135-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28135-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28135-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28135-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28135-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28135-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28135== Time: 2004/01/08 00:46:17 ==28135== Conditional jump or move depends on uninitialised value(s) ==28135== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28135== by 0x3C0012D5: (within /lib/ld-2.2.5.so) -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2004-01-07 13:45:08
|
On Wed, 7 Jan 2004, Tom Hughes wrote: > No existing options require spaces, but the --db-command option that > is in my patch for bug 69489 does as the command to start the debugger > will normally include spaces. > > For the .valgrindrc files it should be difficult if they expect one > option per line, for the env var some form of quoting would have to > be supported. If quoting is supported in the env var (as seems necessary), it shouldn't be hard to support it in the .valgrindrc file too -- I was planning to mmap the .valgrindrc file instead of reading it line by line, so that it can be handled by the same code that handles the env var. N |
|
From: Tom H. <th...@cy...> - 2004-01-07 12:50:34
|
In message <Pin...@re...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 7 Jan 2004, Tom Hughes wrote:
>
>> >> It wouldn't be hard to allow ./.valgrindrc and ~/.valgrindrc files, too,
>> >> which can contain (prefixed and non-prefixed) options, just like the
>> >> VALGRIND_OPTS var.
>> >
>> > I vote for this.
>>
>> Me to. It would be nice if it could handle spaces in option values
>> somehow as well - they are now handled in command line arguments
>
> Really? Do any of the existing options handle them? Does it require
> quoting? Seems like knowing when an option ends and a command name begins
> is problematic if spaces are allowed, eg. in "--foo=bar baz" is "baz" part
> of the --foo option or the name of the executable?
No existing options require spaces, but the --db-command option that
is in my patch for bug 69489 does as the command to start the debugger
will normally include spaces.
For the .valgrindrc files it should be difficult if they expect one
option per line, for the env var some form of quoting would have to
be supported.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-07 12:10:51
|
On Tue, 6 Jan 2004, Ayodele Thomas wrote: > Because of the memory requirements of my skin, I would like to do a > preprocessing step where I look at all of the data addresses produced and > dump a file containing addresses that are read only. Then I > want to read those addresses in and use them. Currently, I > have one skin that does the preprocessing and another than does > the main processing. Does the second step have to be done as a Valgrind skin -- could it be done with a standalone program? Or, can you do the pre-processing and the main processing at the same time? That seems a better way to do things. > However, when I re-execute the code with the > different skin, the memory addresses move and they no longer match up. I think this is because the different skins have different sizes and thus cause memory to be laid out in a different way. When developing Cachegrind, I found that the hit/miss counts would change slightly whenever I made the slightest change to the skin code, for exactly this reason. > Is there a way to force the application to run a second time within the > same skin? (i.e. make two passes). I think then the addresses would be > stable between the two runs. Not that I'm aware of. N |
|
From: Nicholas N. <nj...@ca...> - 2004-01-07 12:04:27
|
On Wed, 7 Jan 2004, Tom Hughes wrote:
> > What about --toolname:option ?
>
> I was thinking much the same thing.
Good idea, I'll do that.
> > BTW, this doesn't allow column chars in any option any more, right?
>
> column chars?
Colon (':') chars? Yes, they wouldn't be allowed, but that doesn't seem
like a great loss? If that's a problem, maybe --toolname::option, or
something even more obscure?
> >> It wouldn't be hard to allow ./.valgrindrc and ~/.valgrindrc files, too,
> >> which can contain (prefixed and non-prefixed) options, just like the
> >> VALGRIND_OPTS var.
> >
> > I vote for this.
>
> Me to. It would be nice if it could handle spaces in option values
> somehow as well - they are now handled in command line arguments
Really? Do any of the existing options handle them? Does it require
quoting? Seems like knowing when an option ends and a command name begins
is problematic if spaces are allowed, eg. in "--foo=bar baz" is "baz" part
of the --foo option or the name of the executable?
> but not currently in argument taken from the environment.
N
|
|
From: Tom H. <th...@cy...> - 2004-01-07 11:02:53
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> Am Montag, 5. Januar 2004 17:34 schrieb Nicholas Nethercote:
>> I was originally thinking of using the syntax "toolname:--option", but
>
> What about --toolname:option ?
I was thinking much the same thing.
> BTW, this doesn't allow column chars in any option any more, right?
column chars?
>> It wouldn't be hard to allow ./.valgrindrc and ~/.valgrindrc files, too,
>> which can contain (prefixed and non-prefixed) options, just like the
>> VALGRIND_OPTS var.
>
> I vote for this.
Me to. It would be nice if it could handle spaces in option values
somehow as well - they are now handled in command line arguments but
not currently in argument taken from the environment.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Josef W. <Jos...@gm...> - 2004-01-07 10:45:27
|
Am Montag, 5. Januar 2004 17:34 schrieb Nicholas Nethercote: > I was originally thinking of using the syntax "toolname:--option", but What about --toolname:option ? BTW, this doesn't allow column chars in any option any more, right? > It wouldn't be hard to allow ./.valgrindrc and ~/.valgrindrc files, too, > which can contain (prefixed and non-prefixed) options, just like the > VALGRIND_OPTS var. I vote for this. Cheers, Josef |
|
From: Jeremy F. <je...@go...> - 2004-01-07 08:48:15
|
CVS commit by fitzhardinge:
Fix "make dist"
M +1 -1 Makefile.am 1.62
M +1 -1 coregrind/arch/Makefile.am 1.3
--- valgrind/Makefile.am #1.61:1.62
@@ -40,5 +40,5 @@
EXTRA_DIST = $(val_DATA) \
FAQ.txt \
- PATCHES_APPLIED ACKNOWLEDGEMENTS \
+ ACKNOWLEDGEMENTS \
README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
--- valgrind/coregrind/arch/Makefile.am #1.2:1.3
@@ -1,2 +1,2 @@
-
+DIST_SUBDIRS=x86-linux x86-freebsd
SUBDIRS=$(VG_PLATFORM)
|
|
From: Jeremy F. <je...@go...> - 2004-01-07 08:47:33
|
CVS commit by fitzhardinge:
Make badrw.c conform to C89; split things onto separate lines so it's
clear what the messages are talking about.
M +6 -6 addrcheck/tests/badrw.stderr.exp 1.4
M +18 -6 memcheck/tests/badrw.c 1.2
M +6 -6 memcheck/tests/badrw.stderr.exp 1.4
--- valgrind/memcheck/tests/badrw.c #1.1:1.2
@@ -5,12 +5,24 @@ int main(void)
void* x = malloc(10);
- int* x4 = x-4;
- short int* x2 = x-4;
- char* x1 = x-1;
+ int *x4;
+ short *x2;
+ char *x1;
+ int y4;
+ short y2;
+ char y1;
+
+ x4 = x-4;
+ x2 = x-4;
+ x1 = x-1;
// Invalid reads and writes of sizes 4, 2, 1
- int y4 = *x4; *x4 = y4;
- short int y2 = *x2; *x2 = y2;
- char y1 = *x1; *x1 = y1;
+ y4 = *x4;
+ *x4 = y4;
+
+ y2 = *x2;
+ *x2 = y2;
+
+ y1 = *x1;
+ *x1 = y1;
return 0;
--- valgrind/memcheck/tests/badrw.stderr.exp #1.3:1.4
@@ -1,4 +1,4 @@
Invalid read of size 4
- at 0x........: main (badrw.c:12)
+ at 0x........: main (badrw.c:19)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -6,5 +6,5 @@
Invalid write of size 4
- at 0x........: main (badrw.c:12)
+ at 0x........: main (badrw.c:20)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -12,5 +12,5 @@
Invalid read of size 2
- at 0x........: main (badrw.c:13)
+ at 0x........: main (badrw.c:22)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -18,5 +18,5 @@
Invalid write of size 2
- at 0x........: main (badrw.c:13)
+ at 0x........: main (badrw.c:23)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -24,5 +24,5 @@
Invalid read of size 1
- at 0x........: main (badrw.c:14)
+ at 0x........: main (badrw.c:25)
Address 0x........ is 1 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -30,5 +30,5 @@
Invalid write of size 1
- at 0x........: main (badrw.c:14)
+ at 0x........: main (badrw.c:26)
Address 0x........ is 1 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
--- valgrind/addrcheck/tests/badrw.stderr.exp #1.3:1.4
@@ -1,4 +1,4 @@
Invalid read of size 4
- at 0x........: main (badrw.c:12)
+ at 0x........: main (badrw.c:19)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -6,5 +6,5 @@
Invalid write of size 4
- at 0x........: main (badrw.c:12)
+ at 0x........: main (badrw.c:20)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -12,5 +12,5 @@
Invalid read of size 2
- at 0x........: main (badrw.c:13)
+ at 0x........: main (badrw.c:22)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -18,5 +18,5 @@
Invalid write of size 2
- at 0x........: main (badrw.c:13)
+ at 0x........: main (badrw.c:23)
Address 0x........ is 4 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -24,5 +24,5 @@
Invalid read of size 1
- at 0x........: main (badrw.c:14)
+ at 0x........: main (badrw.c:25)
Address 0x........ is 1 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
@@ -30,5 +30,5 @@
Invalid write of size 1
- at 0x........: main (badrw.c:14)
+ at 0x........: main (badrw.c:26)
Address 0x........ is 1 bytes before a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
From: Jeremy F. <je...@go...> - 2004-01-07 08:45:19
|
CVS commit by fitzhardinge:
Fix for bug 72006 by Tom Hughes: report proper error returns for mmap()
M +24 -13 vg_syscalls.c 1.76
--- valgrind/coregrind/vg_syscalls.c #1.75:1.76
@@ -3556,4 +3556,5 @@ PRE(mmap2)
POST(mmap2)
{
+ if (!VG_(is_kerror)(res)) {
if (!valid_client_addr(res, arg2, tid, "mmap2")) {
VG_(munmap)((void *)res, arg2);
@@ -3561,4 +3562,5 @@ POST(mmap2)
} else
mmap_segment( (Addr)res, arg2, arg3, arg4, arg5, arg6 * (ULong)VKI_BYTES_PER_PAGE );
+ }
}
@@ -3597,9 +3599,17 @@ PRE(mmap)
if (res != -VKI_ENOMEM) {
- res = (Int)VG_(mmap)((void *)a1, a2, a3, a4 | VKI_MAP_CLIENT, a5, a6);
+ UInt new_arg_block[6];
- if (res == -1)
- res = -VKI_ENOMEM;
- else if (!valid_client_addr(res, a2, tid, "mmap")) {
+ new_arg_block[0] = a1;
+ new_arg_block[1] = a2;
+ new_arg_block[2] = a3;
+ new_arg_block[3] = a4;
+ new_arg_block[4] = a5;
+ new_arg_block[5] = a6;
+
+ res = VG_(do_syscall)(__NR_mmap, new_arg_block);
+
+ if (!VG_(is_kerror)(res)) {
+ if (!valid_client_addr(res, a2, tid, "mmap")) {
VG_(munmap)((void *)res, a2);
res = -VKI_ENOMEM;
@@ -3607,4 +3617,5 @@ PRE(mmap)
mmap_segment( (Addr)res, a2, a3, a4, a5, a6 );
}
+ }
}
|
|
From: Julian S. <js...@ac...> - 2004-01-07 08:23:18
|
> > > This person includes time.h, but I imagine that's not the proper thing > > > to do. No ... vg_profile is a hack for profiling V itself. A possibly better approach is to call VG_(read_millisecond_timer), which uses rdtsc. It isn't incredibly exact, but it should roughly allow you to time intervals of a few milliseconds. J > > > > http://service-spi.web.cern.ch/service-spi/external/valgrind/1.9.5/rh73_g > >cc32/include/vg_profile.c > > > > Sorry. > > > > Nick > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=Click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <ni...@sa...> - 2004-01-07 06:51:16
|
And it's Julian=2E=2E=2E I really have a knack for making myself look foolis= h :) Appologies for sending so many emails to ask 1 little question=2E Nick ----- Original Message ----- From: nick@savs=2Enet Sent: 7/01/2004 5:49:09 PM To: valgrind-developers@lists=2Esourceforge=2Enet Subject: Re: timing information within a skin > >=20 > > This person includes time=2Eh, but I imagine that's not the proper thing= to do=2E > >=20 >=20 > http://service-spi=2Eweb=2Ecern=2Ech/service-spi/external/valgrind/1=2E9=2E= 5/rh73_gcc32/include/vg_profile=2Ec >=20 > Sorry=2E >=20 > Nick |
|
From: <ni...@sa...> - 2004-01-07 06:49:12
|
>=20 > This person includes time=2Eh, but I imagine that's not the proper thing t= o do=2E >=20 http://service-spi=2Eweb=2Ecern=2Ech/service-spi/external/valgrind/1=2E9=2E5= /rh73_gcc32/include/vg_profile=2Ec Sorry=2E Nick |
|
From: <ni...@sa...> - 2004-01-07 06:48:30
|
Hi, Is it possible to get the time of day (gettimeofday() sort of thing), or som= ething to let you calculate how many seconds have passed from within a valgr= ind skin? This person includes time=2Eh, but I imagine that's not the proper thing to = do=2E Thanks, Nick |
|
From: Ayodele T. <em...@st...> - 2004-01-07 00:55:37
|
Because of the memory requirements of my skin, I would like to do a preprocessing step where I look at all of the data addresses produced and dump a file containing addresses that are read only. Then I want to read those addresses in and use them. Currently, I have one skin that does the preprocessing and another than does the main processing. However, when I re-execute the code with the different skin, the memory addresses move and they no longer match up. Is there a way to force the application to run a second time within the same skin? (i.e. make two passes). I think then the addresses would be stable between the two runs. Ayodele -- --------------------------------------------------------------- Ayodele Bolaji Thomas "Joy in the Morning" Ph.D. Candidate Electrical Engineering Computer Systems Laboratory Stanford University Ayo...@st... Support our troops. Support our country. Pray for Peace. \o/ "We succeed, not because of Affirmative Action, but in spite of the conditions that make it necessary" (ABE '98) "War may sometimes be a necessary evil. But no matter how necessary, it is always an evil, never a good. We will not learn to live together in peace by killing each other's children." Jimmy Carter '02 --------------------------------------------------------------- |