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
(1) |
|
2
(28) |
3
(21) |
4
(27) |
5
(22) |
6
(24) |
7
(25) |
8
(21) |
|
9
(18) |
10
(20) |
11
(10) |
12
(36) |
13
(18) |
14
(18) |
15
(29) |
|
16
(17) |
17
(7) |
18
(11) |
19
(17) |
20
(18) |
21
(12) |
22
(13) |
|
23
(9) |
24
(8) |
25
(7) |
26
(22) |
27
(18) |
28
(9) |
29
(15) |
|
30
(13) |
31
(7) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2005-10-30 17:15:59
|
> Done. See attached files lk_main.c and lk-manual.xml. This output is > generated only with command line option --show-guest-details=yes. To > achieve a nice format I had to hack coregrind/m_debuglog.c to: > - accept '*' as width specifier in format strings. Cool. I simplified the instrumentation loop a bit, removed the assumptions about Ity_.. ordering, and changed the output a bit, so it now prints this: ==11136== IR-level counts by type: ==11136== Type Loads Stores AluOps ==11136== ------------------------------------------- ==11136== I1 0 0 647,904,654 ==11136== I8 43,422,956 10,545,468 102,858,666 ==11136== I16 11,699,415 1,784,133 4,123,740 ==11136== I32 743,727,534 467,327,806 2,151,045,236 ==11136== I64 11,107 1,921 1,702,131 ==11136== I128 0 0 0 ==11136== F32 1,999,224 75 75 ==11136== F64 3,900,295 999,008 11,441,729 ==11136== V128 0 0 0 ==11136== It does run slowly though, largely as a result of doing at least one helper call per IR stmt. Maybe that's not important. J |
|
From: Bryan M. <om...@br...> - 2005-10-30 17:08:49
|
On Sunday 30 Oct 2005 16:50, Tom Hughes wrote: > In message <200...@br...> > Bryan Meredith <om...@br...> wrote: > > > A Simple Example > > ---------------- > > The program under test calls malloc (or one of the other heap allocation > > functions). We generate an internal record to track the address and size of > > the new block and set the 'V' bits of the shadow register to indicate 'valid > > (0)'. Note that as with MemCheck, the default state of all shadow memory is > > 'invalid (1)'. > > > > Immediately before the register is written out to memory, we create a new > > temporary register that contains the result of a bitwise AND between the 'V' > > bits of the register and the memory location to be written. We now call a > > helper function passing this register. If the results of the AND is '0', we > > know that there is a state change that we have to track and so process > > accordingly, adding and/or deleting new back references in the internal > > record and generating user diagnostic as required. > > This sounds like you are doing the tracking at bit level which seems a > bit wasteful - surely the most you need to track at is byte level (more > like memcheck's A bits) or even word level? Very true - it is memory intensive - the alternate is very processor intensive and you are forced to do lookups and caching in internal structures instead. Although this is bit level, we set all the bits one way or the other in one go - there is no mixing of defined and undefined values. As you can see further down, internally there is a mechanism for tracking pointers in 64k chunks of memory (each bit represents either 4 or 8 bytes). The downside is the expense of doing a lookup every time we read or write memory - thats why I went for the faster (but more memory intensive) 'V' bit technique. > > It also isn't clear to me that your scheme will cope with pointers that > never make it to memory - if I allocate memory with the pointer going > into a register and then that register is overwritten without the memory > being freed will you spot it? > > Presumably you could spot that because a write to a register that had > it's V bits set to zero could check that the block the register was > pointing to had other pointers? Yes - it can be tracked but I wasnt planning to. This is one of the ommisions / over simplifications that I mentioned. As I put in the example of what we dont track, this should be easilly spotted after a MemCheck run as the pointer wont be making it out of the function that calls the allocator. > > > As a later feature addition, it should be possible through some mechanism > > (possibly the suppression functionality) to indicate that a pointer at some > > positive offset to the allocated memory address should also be tracked. This > > would be of benefit to those that implement their own memory management. > > I suspect some way of coping with this will be needed - I know that our > code base at work has some widely used data structures where only an > interior pointer is kept around. Indeed - we have this issue as well so it is definitely desireable. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > Thanks for the rapid feedback! Bryan "Brain Murders" Meredith |
|
From: Tom H. <to...@co...> - 2005-10-30 16:50:51
|
In message <200...@br...>
Bryan Meredith <om...@br...> wrote:
> A Simple Example
> ----------------
> The program under test calls malloc (or one of the other heap allocation
> functions). We generate an internal record to track the address and size of
> the new block and set the 'V' bits of the shadow register to indicate 'valid
> (0)'. Note that as with MemCheck, the default state of all shadow memory is
> 'invalid (1)'.
>
> Immediately before the register is written out to memory, we create a new
> temporary register that contains the result of a bitwise AND between the 'V'
> bits of the register and the memory location to be written. We now call a
> helper function passing this register. If the results of the AND is '0', we
> know that there is a state change that we have to track and so process
> accordingly, adding and/or deleting new back references in the internal
> record and generating user diagnostic as required.
This sounds like you are doing the tracking at bit level which seems a
bit wasteful - surely the most you need to track at is byte level (more
like memcheck's A bits) or even word level?
It also isn't clear to me that your scheme will cope with pointers that
never make it to memory - if I allocate memory with the pointer going
into a register and then that register is overwritten without the memory
being freed will you spot it?
Presumably you could spot that because a write to a register that had
it's V bits set to zero could check that the block the register was
pointing to had other pointers?
> As a later feature addition, it should be possible through some mechanism
> (possibly the suppression functionality) to indicate that a pointer at some
> positive offset to the allocated memory address should also be tracked. This
> would be of benefit to those that implement their own memory management.
I suspect some way of coping with this will be needed - I know that our
code base at work has some widely used data structures where only an
interior pointer is kept around.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bryan M. <om...@br...> - 2005-10-30 16:37:11
|
Dear Valgrind Team,
Title
=====
Omega - A Valgrind tool for instant memory leak detection.
Designed by Bryan "Brain Murders" Meredith with grateful thanks to the
Valgrind team for making their tool and techniques available under the GPL.
Synopsis
========
Whilst Valgrind's MemCheck tool can currently detect and report that a memory
leak has occurred, the debugging output only shows where the memory that has
leaked was allocated. There are no clues as to where the last reference to
the allocated block was lost. Omega uses a modified version of MemCheck's
"definedness" ('V' bit tracking) technique in order to help track pointers to
allocated memory, outputting debugging information when the final (hence
Omega) pointer to an allocated block is over-written or lost through a call
to free() or the stack unwinding.
How it Works
============
The critical point in tracking leaking pointers is when a value is written
into memory from a register. This can result in the creation of a new
reference to an allocated block, the destruction of a current reference to an
allocated block or both. If we determine that either the register to be
written or the memory location to be written contains a pointer that we are
tracking, we update our tracking system and report if we are losing the last
pointer to a block.
Because checking every single write to memory is going to cause a huge
overhead, we use a modified version of MemCheck's 'V' bit tracking to give us
a simple "are we dealing with a tracked pointer" check before we go on to
more heavyweight processing.
A Simple Example
----------------
The program under test calls malloc (or one of the other heap allocation
functions). We generate an internal record to track the address and size of
the new block and set the 'V' bits of the shadow register to indicate 'valid
(0)'. Note that as with MemCheck, the default state of all shadow memory is
'invalid (1)'.
Immediately before the register is written out to memory, we create a new
temporary register that contains the result of a bitwise AND between the 'V'
bits of the register and the memory location to be written. We now call a
helper function passing this register. If the results of the AND is '0', we
know that there is a state change that we have to track and so process
accordingly, adding and/or deleting new back references in the internal
record and generating user diagnostic as required.
When we call free (or one of the other heap de-allocation functions), we do
cleanup processing on our internal record. There are two key activities that
must be performed at this point.
1) Set 'V' bits to any hanging pointers to 'invalid'.
2) Recursively remove references to any pointers that are within the memory
area that we are about to free.
As an option, during part 1 we could report on the hanging pointers.
Note that stack unwinding would also perform part 2 to ensure that we don't
leak through automatic variables going out of scope.
'V' bit Propagation
-------------------
Unlike MemCheck, we only have one size of data to track - namely sizeof(void
*). Another key difference is that we need the pointer to be unmolested for
it to be of interest to us. The upshot of these two properties are that in
the first version of Omega, not only can we further limit our checks to
transfers of the appropriate width and alignment but any operation that
changes the value during propagation causes the 'V' bits to be set to
'invalid', thus saving us from performing the expensive lookups and
processing.
As a later feature addition, it should be possible through some mechanism
(possibly the suppression functionality) to indicate that a pointer at some
positive offset to the allocated memory address should also be tracked. This
would be of benefit to those that implement their own memory management.
Optimisation
------------
As part of the tracking process, we also hold a sparse bitmap in nodes that
cover an area of memory 64kB in size. Each bit within a bitmap node
represents an aligned pointer in memory. The point of this second reference
is to assist in the detection of tracked references within the stack and
allocated memory blocks. Due to the compressed nature of the information, we
can check if an area of memory is free of tracked pointers 32 possible
pointers at a time.
What We Can Detect
==================
Using the above techniques, we can track the following leaks:
Simple over-write of a tracked pointer.
lastP = blah;
Tracked pointer being modified.
lastP++;
Automatic variable going out of scope.
{
void *lastP = malloc(64);
return;
}
Tracked pointer within allocated block being returned to OS.
{
void *arrayP = malloc(10 * sizeof(void *));
arrayP[1] = malloc(64);
free(arrayP);
}
What We Don't Detect
--------------------
This never results in the tracked pointer being saved into memory.
It should be possible to add some state tracking to check if an allocated
block has references when the stack unwinds but this sort of thing is usually
either deliberate or easily fixed after a run through MemCheck.
{
new CFred();
return;
}
What Next?
==========
I have to code it ;P
I have produced this in order to obtain feedback as soon as possible on what
will be a very useful tool both to my company and hopefully others. Any and
all feedback gratefully received. I understand that some parts have probably
been oversimplified and testing of the first implementation will reveal some
shortcomings. The main thing is that the principle of using the 'V' bits to
track pointers to allocated blocks is sound - implementation of the internal
data structures for the allocated blocks, the reverse lookups and handling
can be optimised over time as required and thus is not detailed here. This is
not to say that I don't have a solution, it's just that it is one of many
possible so not as interesting.
The above description can also be read here:
http://www.brainmurders.eclipse.co.uk/omega_introduction.txt
Thanks for your time and looking forward to any feedback that you might wish
to give.
Bryan "Brain Murders" Meredith
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-30 12:30:30
|
On Sun, 30 Oct 2005, Julian Seward wrote:
>
> Jeroen, great stuff.
>
>> >> - To count the number of guest instructions, I count the number of
>> >> Ist_IMark statements executed. Is this the correct approach?
>> >
>> > Yes.
>
> Yes, although you can (optionally) use a different strategy which is
> cheaper. Rather than call add_one_guest_instr each time an IMark
> is passed, make the instrumentation loop increment a counter when
> it passes an IMark. Then, either at the end of the BB or when you
> get to an Ist_Exit, call a (new) fn add_N_guest_instrs and pass it
> the counter. Then reset the counter to zero. In other words,
> call the instruction-counting function once for each piece of
> straight-line code. Cachegrind uses a similar strategy.
>
> I'm not saying you should do this, considering lackey is supposed
> to be a simple tool example, but it is a possible go-faster option.
>
I don't like to burden Lackey with this, but I'll keep it in mind for the
next tool I'm working on: Blanket, a basic code coverage tool (mentioned
in '3.2.2. Suggested tools' in file docs/xml/writing-tools.xml).
> Depending on what Nick thinks, and your hacking enthusiasm, there is
> something that would make Lackey more useful whilst still being a
> nice simple demo of how to make a tool. That is, generate counts
> for all the following events:
>
> guest instructions
> conditional branches (split into: taken, not taken)
> loads (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
> stores (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
> alu ops (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
>
> Someone on the users list asked for something like this just the
> other day (Christian Stimming, "Fast profiling in valgrind?", 25 Oct).
> Personally I think it'd be a valuable addition.
>
> Not hard to do either: for stores, examine Ist_Store, and use
> typeOfIRExpr(bb->tyenv, st->Ist.Store.data) to get the store type.
> For loads and ALU ops, you only need to look at Ist_Tmp cases
> where the Ist.Tmp.data is either Iex_Load or Iex_{Unop,Binop}.
> All statements you will ever encounter will satisfy isFlatIRStmt
> which essentially constrains them to being flat SSA-style.
>
Done. See attached files lk_main.c and lk-manual.xml. This output is
generated only with command line option --show-guest-details=yes. To
achieve a nice format I had to hack coregrind/m_debuglog.c to:
- accept '*' as width specifier in format strings.
- fix the interpretation of VG_MSG_LJUSTIFY for strings, which was turned
around.
See attached file coregrind/m_debuglog.c.diff.
Some notes:
- Binary operations are counted under the type of their first argument.
The second argument is ignored.
- With the changes I made in the output, the regression test for Lackey
should fail, but does not, and I don't see why.
Jeroen.
>> >> - In the 'switch (st->tag)' statement, the 'case Ist_Exit:' adds a
>> deep
>> >> copy of the statement to bb; whereas the 'default:' adds the
>> statement
>> >> itself. Is there a rationale behind this difference?
>
> No .. me being over cautious. I'm pretty sure you can simply copy
> the statements themselves; doing deep copies just makes the instrumenter
> run slower :-)
>
>> 190 in attached file lk_main.c), I had to change the format from %u to
>> %llu to get it to work properly.
>
> %llu is the correct format for ULong, yes.
>
> J
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: <js...@ac...> - 2005-10-30 03:49:30
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-10-30 03:30:00 GMT 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 == 201 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2005-10-30 03:44:39
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-10-30 04:40:00 CET 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 == 170 tests, 20 stderr failures, 2 stdout failures ================= memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stderr) massif/tests/toobig-allocs (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2005-10-30 03:40:32
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-10-30 03:30:04 GMT 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 == 203 tests, 11 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-30 03:28:56
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-10-30 03:15:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 202 tests, 16 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 202 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 30 03:21:51 2005 --- new.short Sun Oct 30 03:28:48 2005 *************** *** 8,10 **** ! == 202 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) --- 8,10 ---- ! == 202 tests, 16 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) *************** *** 25,26 **** --- 25,27 ---- none/tests/x86/int (stderr) + none/tests/x86/yield (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-30 03:22:15
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-10-30 03:00:03 GMT 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 == 177 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-30 03:20:58
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-10-30 03:10:08 GMT 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 == 177 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-30 03:19:14
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-10-30 03:05:11 GMT 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 == 177 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2005-10-30 01:03:46
|
Jeroen, great stuff.
> >> - To count the number of guest instructions, I count the number of
> >> Ist_IMark statements executed. Is this the correct approach?
> >
> > Yes.
Yes, although you can (optionally) use a different strategy which is
cheaper. Rather than call add_one_guest_instr each time an IMark
is passed, make the instrumentation loop increment a counter when
it passes an IMark. Then, either at the end of the BB or when you
get to an Ist_Exit, call a (new) fn add_N_guest_instrs and pass it
the counter. Then reset the counter to zero. In other words,
call the instruction-counting function once for each piece of
straight-line code. Cachegrind uses a similar strategy.
I'm not saying you should do this, considering lackey is supposed
to be a simple tool example, but it is a possible go-faster option.
Depending on what Nick thinks, and your hacking enthusiasm, there is
something that would make Lackey more useful whilst still being a
nice simple demo of how to make a tool. That is, generate counts
for all the following events:
guest instructions
conditional branches (split into: taken, not taken)
loads (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
stores (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
alu ops (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
Someone on the users list asked for something like this just the
other day (Christian Stimming, "Fast profiling in valgrind?", 25 Oct).
Personally I think it'd be a valuable addition.
Not hard to do either: for stores, examine Ist_Store, and use
typeOfIRExpr(bb->tyenv, st->Ist.Store.data) to get the store type.
For loads and ALU ops, you only need to look at Ist_Tmp cases
where the Ist.Tmp.data is either Iex_Load or Iex_{Unop,Binop}.
All statements you will ever encounter will satisfy isFlatIRStmt
which essentially constrains them to being flat SSA-style.
> >> - In the 'switch (st->tag)' statement, the 'case Ist_Exit:' adds a deep
> >> copy of the statement to bb; whereas the 'default:' adds the statement
> >> itself. Is there a rationale behind this difference?
No .. me being over cautious. I'm pretty sure you can simply copy
the statements themselves; doing deep copies just makes the instrumenter
run slower :-)
> 190 in attached file lk_main.c), I had to change the format from %u to
> %llu to get it to work properly.
%llu is the correct format for ULong, yes.
J
|