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
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Julian S. <js...@ac...> - 2006-09-02 11:17:52
|
On Saturday 02 September 2006 08:22, Oswald Buddenhagen wrote: > On Sat, Sep 02, 2006 at 03:18:56AM +0100, Julian Seward wrote: > > Recording program counters without a stack is of limited use, but I > > can't see how to record a complete stack for each first-write without > > huge space/time overheads. It might be possible to devise a highly > > compressed representation for just the PC values, based on the idea > > that each segment is only going to use a tiny subset of the 2^32/2^64 > > possible PC values. > > i think saving traces in a tree might work. sounds a bit like callgrind. Can you give a bit more detail on that? I'm not sure what you mean. J |
|
From: <js...@ac...> - 2006-09-02 11:08:57
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-02 09:00:01 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Oswald B. <os...@kd...> - 2006-09-02 07:22:09
|
On Sat, Sep 02, 2006 at 03:18:56AM +0100, Julian Seward wrote: > Recording program counters without a stack is of limited use, but I > can't see how to record a complete stack for each first-write without > huge space/time overheads. It might be possible to devise a highly > compressed representation for just the PC values, based on the idea > that each segment is only going to use a tiny subset of the 2^32/2^64 > possible PC values. > i think saving traces in a tree might work. sounds a bit like callgrind. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: <js...@ac...> - 2006-09-02 04:05:18
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-09-02 04:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-02 03:12:29
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-02 03:00:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/tls (stdout) |
|
From: Tom H. <to...@co...> - 2006-09-02 02:45:42
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-02 03:30:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 239 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-02 02:25:22
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-02 03:10:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-02 02:24:29
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-02 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccCADW43.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCADW43.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.27204/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.27204/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.27204/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.27204/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.27204/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccWlzaIu.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccWlzaIu.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.27204/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.27204/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.27204/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.27204/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.27204/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Sep 2 03:19:45 2006 --- new.short Sat Sep 2 03:24:24 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccWlzaIu.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccWlzaIu.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccCADW43.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCADW43.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-02 02:20:29
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-02 03:05:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2006-09-02 02:19:14
|
I'm pleased to see that 'drd', Bart's data race detection tool, has=20
recently progressed to the point where we can start to evaluate it.
A robust, accurate, data race detection tool would be an excellent=20
addition to our tool suite, and drd is making promising noises.
There's still a way to go, however. I've been thinking about why
drd is difficult to use, what can be done to improve it.
When it reports a race, drd says, basically
I found a race between two thread segments
Here's the first segment: thread X, starting stack S1,=20
ending stack E1
Here's the second segment: thread Y, starting stack S2,
ending stack E2
Here are the data addresses ("contended addresses") involved in=20
the race:
0xF00, 0xBAR, 0xXYZZY
If you get lucky, it may identify those addresses as being global
data symbols, or inside malloc'd blocks, but often it doesn't.
That's good as far as it goes. For small programs, that kind
of info is often enough to make sense of the race. But playing with=20
drd on knode (threaded news reader in KDE 3.5.4), I find I haven't
a clue what's going on. Ok, I'm not familar with knode (or KDE, or
Qt at all), but nevertheless I look at what drd tells me and I still
am completely unable to identify which parts of the sources might
be involved in the race.
What drd tells us is the data addresses involved in the race
(is "contended addresses" a good name for them?) Problem is,
unless you are extremely lucky, the program is tiny, or you=20
are a total genius, it's nearly impossible to figure out where
in the code these reads/writes are being done.
The DIOTA papers mention the idea of a replay tool associated with
the race detector. In a first run, the race addresses are computed
by a drd-like tool. The program is then re-run under the control of
a "deterministic replay tool", which somehow manages to recreate the
previous execution, the purpose being to monitor all reads/writes so
it can take snapshots of the thread stacks when it detects accesses
to the race addresses. This presumably makes it simple to relate the
racing to source code locations.
It's a nice idea, but I don't think it's practical here. I don't see
how the replay tool can work for interactive applications like web
browsers. And I don't think users will appreciate the hassle.
So here's a different impractical idea :-) When drd is recording
races, don't just record the set of read/written addresses, but
something else too: for each written address in the segment, also
record the program counter of the first (or any) writer of that address.
By definition a race must involve at least one of the threads writing
the contended address(es). So this is guaranteed to produce at least=20
one source code location involved in the race. Now the error report
might look like this:
[.. other stuff as before ..]
Here's the data addresses involved in the race:
0xF00 (first write in segment 1, abcd.c:124),=20
0xBAR (first write in segment 2, snafu.cpp:678),
0xXYZZY (first write in segment 1, spqr.c:987
and in segment 2, badness.c:666)
Recording program counters without a stack is of limited use, but I
can't see how to record a complete stack for each first-write without
huge space/time overheads. It might be possible to devise a highly=20
compressed representation for just the PC values, based on the idea=20
that each segment is only going to use a tiny subset of the 2^32/2^64
possible PC values.
=46rom reading the DIOTA papers I got the impression they did a lot of
work to make DIOTA fast and memory efficient, but I didn't see much stuff
about what the tool was like to use in practice. Maybe I didn't look
in the right places.
J
|
|
From: Julian S. <js...@ac...> - 2006-09-02 01:34:39
|
Now that 3.2.0 is out, and 3.2.1 is not far away, I've been musing about what sorts of things might go into a 3.3 line of Valgrind. Here are some suggestions for discussion. J Comments on upcoming releases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am hoping to roll 3.2.1 soon (in the next couple of weeks). 3.2.0 seems to have been pretty stable, but enough bugs have cropped up, a couple of them serious, to make 3.2.1 worthwhile. I've found that making major releases (3.X.0) is a major hassle. 3.1.0 and 3.2.0 each took two weeks full time by the time all the regression test fixing, packaging and testing on 99 different platforms is done. As a consequence: * I prefer not to release 3.3.0 until early next year. * We should keep 3.2.X going longer than 3.1.X and 3.0.X stayed alive, with at least a 3.2.2 release some time around November. * It would be nice to have a second person to help with some of the testing work for 3.3.0. New tools for 3.3.0 ~~~~~~~~~~~~~~~~~~~ In 3.X so far the primary emphasis has been on portability, stability and speed. Now there are some new tools under development (drd, omega, covergrind) and some old experimental ones, in various states of disrepair, which it would be nice to play with from time to time (annelid, diduce, helgrind). I've been thinking of splitting the tools into two groups: production-grade tools (memcheck, cachegrind, callgrind, massif) and experimental tools (drd, omega, covergrind, annelid, diduce, helgrind), and having both sets in the standard Valgrind tree. For production tools we would continue to ensure they have high quality and are stable, as at present. For experimental tools we would try to ensure they compile, but give no assurance beyond that. The problem with experimental tools is they need a lot of engineering effort to get them to a production status (or conclusion that the tool cannot be moved to production status for technical reasons.) Getting that effort means having users try them out and contribute feedback and patches. Putting the tools in the tree, and having them compile, even if they don't work well, makes it a lot easier for users to do that. It's also more inclusive for the tool authors. There are downsides: - more code in the tree inevitably means a higher maintenance overhead - stability of the existing code base is important, and we don't want to undermine that I'm thinking of an arrangement in which experimental tool authors have commit access to the tree, but - we make it clear it is their responsibility to keep tools compiling and working - we ask that such authors do not commit changes outside of their individual tools without first consulting with the core developers New ports for 3.3.0 ~~~~~~~~~~~~~~~~~~~ This year there has been quiet but steady work towards porting V away from Linux. There are now ports to FreeBSD, MacOSX and AIX5 in various states of progress, and it seems likely that some of those will appear in the mainline tree at some point. I am expecting that our existing porting infrastructure will continue to be refined and extended so that these ports can be accommodated without majorly intrusive changes in the majority of the code base. So far with the Linux ports to x86,amd64,ppc32,ppc64, the target-specific stuff has been isolated into a relatively few places (eg, m_syswrap, m_sigframe, m_syscall, VEX), leaving the rest of the system fairly untouched, and I am hoping this can be continued. The regression test infrastructure has proven invaluable in making V as reliable as it is. However, even with Linux it is too sensitive to changes in stack backtraces and address space layouts, and as a result causes tests to fail when really they should succeed. With new ports on the horizon this problem is about to get much worse. If anyone is motivated to overhaul this unglamorous but critical subsystem, that would be much appreciated. |
|
From: Julian S. <js...@ac...> - 2006-09-01 13:18:28
|
I can see that some info like that would be helpful, but I'm concerned
that it might be a case of fixing the symptoms (and/or adding a fix
which makes sense only for eg x86 and not generally).
What I think would be helpful is to make a concise, semi-formal
statement of the problem. I think this would help by showing how this
relates to standard compiler concepts of liveness and reachability.
In particular I'd like to find a solution which gives accurate results
and which works well even in the presence of optimised code, which AIUI
Omega currently doesn't.
My initial thoughts at such a statement are:
- keep track of all allocated blocks
- keep track of all potential roots. Potential roots at any
time are
* the words in all currently accessible memory, plus the words
in the registers
BUT
only those for which the next event is a read
- If some part of the address space disappears, that can be thought of
as a write.
- If a write (to a potential root) happens, and that destroys the last
pointer to a particular block, then we can complain at that point
of a leak.
- However, that may be too late. (as per current example)
What we really want to find is something along the lines of
'dead writes' (to registers and memory). A dead write puts a value
into that storage location which is never read, only overwritten
(or the storage location goes out of scope, which is equivalent).
Perhaps it should be that a leak is reported at a dead write of
the last pointer to a block. Or something. Anyway, the general
idea is: if you can characterise the problem in terms of dataflow
and liveness, perhaps it becomes possible to build an implementation
which is robust to ABI changes, compiler optimisation, and across
different platforms.
The above ideas are half-baked; don't take the details too literally.
---
Another thing that would help (perhaps the same thing, really)
is to give a very precise specification of what the tool is intended
to do.
Originally I had the impression that it was "find where the last pointer
to block X is overwritten"; but when looked at under a magnifying glass
it's clear this can lead to error reports which point to some location
in the code flow which may be arbitrarily far after the place where you
really wanted to report the error. So (and I think this is the crux
of the problem) how do you precisely specify those program points where
you *do* want to report an error?
J
On Thursday 31 August 2006 21:18, Bryan Meredith wrote:
> Julian,
>
> looking in readdwarf.c and storage.c, I think I can put a patch together
> that adds a flag into DiSym in order to indicate "no return", "return"
> or "unknown" (for when the debug isn't there and it's time to hit a
> fall-back method - this would also be the default value).
>
> Would it be of interest? I don't want to spend time doing this if its
> not going to go in (pending code review etc of course).
>
> My idea is to extend the read_unitinfo_dwarf2 function by a) passing in
> the seginfo pointer in order to give access to the symtab and b) to
> parse out TAG_subprogram entries.
>
> Basically, a void function has no type (AT_type) entry. Once a
> subprogram is fully parsed, search_one_symtab can be used to find the
> related DiSym and then update the entry from the default "unknown".
>
> Bryan
>
> Bryan Meredith wrote:
> > Julian Seward wrote:
> >>> Looking at the two programs side by side, I think the real crux of it
> >>> is the differing epilog code. I think I am falling over trying to
> >>> detect when there is a value being returned through the accumulator.
> >>
> >> This sounds like a dataflow/liveness problem. So, let me unwind
> >> one more level. Why do you want to know whether the accumulator
> >> contains a live vs dead value at the point the function returns?
> >> What are you going to do with that info?
> >>
> >> J
> >
> > Julian,
> >
> > that's exactly the problem. If the accumulator holds a pointer to a
> > memory block and is live, it should be left alone and tracked out of the
> > function. If it is dead, it should be culled as the function exits,
> > possibly generating a leak report if it is the final pointer to that
> > block.
> >
> > If the pointer is dead but is left until it is over-written, the
> > location of the leak report is inaccurate.
> >
> > The ability to detect the dead value allows function scope related
> > checking for leaks. As an example (this is scope2.c in the test
> > directory):
> >
> > #include <stdlib.h>
> >
> > static void func1(void)
> > {
> > char *pointer = 0;
> >
> > pointer = malloc(64); /* Line 7 */
> >
> > return;
> > } /* Leak report Line 10 */
> >
> > int main(int argc, char *argv[])
> > {
> > func1();
> >
> > return 0; /* Line 16 */
> > }
> >
> > At line 7, the malloc() call returns the pointer in the accumulator
> > which is then also saved into the stack variable "pointer". As the
> > function exits, the stack unwinds, removing the reference in "pointer"
> > but the accumulator will still hold a reference. If the accumulator is
> > detected as being dead, a leak report will be generated at line 10 as we
> > remove the reference it is holding and discover it is the last one. If
> > we don't invalidate the accumulator, we get the leak report at line 16
> > instead when the reference is overwritten by 0 in order to be returned
> > by main().
> >
> > A report at line 16 is not only inferior to a report at line 10, it is
> > not going to provide the clarity that Omega should supply in it's goal
> > to assist in tracking down memory leaks: a report at line 10 makes it
> > pretty obvious that something went out of scope whilst a report at line
> > 16 will leave most people scratching their heads.
> >
> > It's pretty fundamental to the whole thing which is why I could do with
> > a robust method for determining when to cull registers on exit and when
> > to leave them alone - the ABI is simply not enough.
> >
> > Hope that explains it,
> > Bryan
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: <js...@ac...> - 2006-09-01 11:01:39
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-01 09:00:01 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2006-09-01 04:06:57
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-09-01 04:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-01 03:21:25
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-01 03:00:08 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/tls (stdout) |
|
From: Tom H. <to...@co...> - 2006-09-01 02:45:30
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-01 03:30:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 239 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2006-09-01 02:45:25
|
Should I push this (and/or r6044) into 3.2.1 ?
J
On Thursday 31 August 2006 20:29, sv...@va... wrote:
> Author: weidendo
> Date: 2006-08-31 20:29:13 +0100 (Thu, 31 Aug 2006)
> New Revision: 6043
>
> Log:
> callgrind: Fix warning about malformed creator line in annotate script
>
> This also changes the default filename (if not given) to callgrind.out.*
>
> Modified:
> trunk/callgrind/callgrind_annotate.in
>
>
> Modified: trunk/callgrind/callgrind_annotate.in
> ===================================================================
> --- trunk/callgrind/callgrind_annotate.in 2006-08-31 11:08:59 UTC (rev
> 6042) +++ trunk/callgrind/callgrind_annotate.in 2006-08-31 19:29:13 UTC
> (rev 6043) @@ -100,6 +100,7 @@
> my $cmd = "";
>
> # Info on the profiled process.
> +my $creator = "";
> my $pid = "";
> my $part = "";
> my $thread = "";
> @@ -310,10 +311,12 @@
> }
>
> if ($input_file eq "") {
> - $input_file = (<cachegrind.out*>)[0];
> + $input_file = (<callgrind.out*>)[0];
> if (!defined $input_file) {
> - $input_file = "cachegrind.out";
> + $input_file = (<cachegrind.out*>)[0];
> }
> +
> + (defined $input_file) or die($usage);
> print "Reading data from '$input_file'...\n";
> }
> }
> @@ -403,6 +406,7 @@
> else { $desc .= "$dline\n"; }
> }
> elsif (/^cmd:\s+(.*)$/) { $cmd = $1; }
> + elsif (/^creator:\s+(.*)$/) { $creator = $1; }
> elsif (/^positions:\s+(.*)$/) {
> my $positions = $1;
> $has_line = ($positions =~ /line/);
> @@ -670,6 +674,11 @@
> sub print_options ()
> {
> print($fancy);
> + print "Profile data file '$input_file'";
> + if ($creator ne "") { print " (creator: $creator)"; }
> + print "\n";
> +
> + print($fancy);
> print($desc);
> my $target = $cmd;
> if ($pid ne "") {
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Tom H. <th...@cy...> - 2006-09-01 02:25:28
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-01 03:10:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-01 02:24:19
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-01 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccgBSkHf.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.32326/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.32326/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccbpx6z9.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.32326/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.32326/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Sep 1 03:19:38 2006 --- new.short Fri Sep 1 03:24:14 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccbpx6z9.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccgBSkHf.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-01 02:20:29
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-01 03:05:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |