You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
(7) |
3
(4) |
4
(6) |
5
(6) |
6
(4) |
|
7
|
8
(6) |
9
|
10
|
11
(10) |
12
(5) |
13
(2) |
|
14
(3) |
15
(3) |
16
(14) |
17
(7) |
18
(7) |
19
(5) |
20
(4) |
|
21
(5) |
22
(5) |
23
(3) |
24
(11) |
25
(5) |
26
(9) |
27
(5) |
|
28
(2) |
29
(7) |
30
(3) |
31
(2) |
|
|
|
|
From: Jukka K. <muo...@ho...> - 2004-03-25 22:11:33
|
So this is what I tested:
#include <pthread.h>
#include <unistd.h>
void* handler (void *ptr)
{
return NULL;
}
int main()
{
pthread_t p;
pthread_create (&p, NULL, handler, NULL);
sleep (1);
return (0);
}
and I got this:
==6411== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==6411== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==6411== Using valgrind-2.0.0, a program supervision framework for
x86-linux.
==6411== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==6411== Estimated CPU clock rate is 1819 MHz
==6411== For more details, rerun with: -v
==6411==
==6411==
==6411== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==6411== malloc/free: in use at exit: 200 bytes in 1 blocks.
==6411== malloc/free: 3 allocs, 2 frees, 214 bytes allocated.
==6411== For counts of detected errors, rerun with: -v
==6411== searching for pointers to 1 not-freed blocks.
==6411== checked 4622480 bytes.
==6411==
==6411== LEAK SUMMARY:
==6411== definitely lost: 0 bytes in 0 blocks.
==6411== possibly lost: 0 bytes in 0 blocks.
==6411== still reachable: 0 bytes in 0 blocks.
==6411== suppressed: 200 bytes in 1 blocks.
==6411== Reachable blocks (those to which a pointer was found) are not
shown.
==6411== To see them, rerun with: --show-reachable=yes
==6411==
3 allocs and 2 frees? suppressed 200... ?
: JK
_________________________________________________________________
Nopea ja hauska tapa lähettää viestejä reaaliaikaisesti - MSN Messenger.
http://messenger.msn.fi Lataa nyt käyttöösi ilmaiseksi.
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-25 18:51:40
|
On Thu, 25 Mar 2004, Xavier Bestel wrote: > during a valgrind session I stumbled on that (this is the first error): > > ==22013== Invalid read of size 1 > .... > ==22013== Address 0x48C1D128 is not stack'd, malloc'd or free'd > > > When I attach to gdb at this point, and I examine the content of memory > at 0x48C1D128 (to which a char* is pointing), I find a string which > really seems like it has been written by my program. > > How is this possible ? How could my program write to a non stack'd, > malloc'd or free'd address before this point and not been caught by > valgrind ? It does seem a bit strange. Can you write a small example program that shows the problem? N |
|
From: Xavier B. <xav...@fr...> - 2004-03-25 18:18:32
|
Hi, during a valgrind session I stumbled on that (this is the first error): ==22013== Invalid read of size 1 .... ==22013== Address 0x48C1D128 is not stack'd, malloc'd or free'd When I attach to gdb at this point, and I examine the content of memory at 0x48C1D128 (to which a char* is pointing), I find a string which really seems like it has been written by my program. How is this possible ? How could my program write to a non stack'd, malloc'd or free'd address before this point and not been caught by valgrind ? Thanks for your enlightenments, Xav Please Cc: me |
|
From: Josef W. <Jos...@gm...> - 2004-03-25 09:55:55
|
On Thursday 25 March 2004 09:43, Nicholas Nethercote wrote:
> On Wed, 24 Mar 2004, Josef Weidendorfer wrote:
> > You are right. It's only a matter of writing a conversion script from
> > massif data (raw/ASCII ?) to cachegrind/calltree format.
> > KCachegrind should be able to cope with multiple cachegrind/calltree
> > simple concatenated together (for multiple consensi). The format is
> > described in a HTML documentation in the calltree package.
> > Any volunteers?
>
> I'm not sure about this. With (K)Cachegrind, you have a figure for every
> instruction in the program, and these get mapped onto individual lines.
> For Massif, you don't really have a spacetime figure for every
> instruction. I think you'd only be annotating lines containing a function
> call that allocates memory, or that (eventually) calls a function that
> allocated memory? Eg, in this (nonsense) program:
Yes.
Source Annotation does not make much sense in this case.
If you have allocation contexts, you can construct some kind of call graph out
of this, and calculate inclusive costs in the conversion.
I'm not really sure if the result is worth it, but it looks easy to do.
> int* f(void)
> {
> return malloc(1000); // 11 * 1000 * t
> }
>
> int* g(void)
> {
> bar();
> for (i = 0; i < 10; i++)
> f(); // 10 * 1000 * t
Here we add: "Call to f with inclusive cost of 10 * 1000
> return f(); // 1 * 1000 * t
Here we add: "Call to f with inclusive cost of 1 * 1000
> }
>
> int* h(void)
> {
> foo();
> x = y + z;
> return g(); // 11 * 1000 * t
> }
>
>
> (where 't' is the length of time all the blocks are in existence for).
> The comments show where the annotations would go; I'm assuming h() is
> only called once.
>
> Is that right?
Yes. The numbers of the contexts would be present in inclusive costs.
I'm not sure: Would the location of the call sites be available for annotation
purpose?
On a side note:
As I managed to run OProfile on my Pentium-M notebook, I'm more interested in
a import/conversion of the sample data from OProfile.
My vision is to use call graph data from Calltree for a run of a program, and
be able to add estimations for inclusive costs to the sampling results of
OProfile for the same (deterministic) program, assuming same calls.
This would be a way to get inclusive costs for all kind of performance metrics
on all architectures where OProfile can run (AMD64, PowerPC, IA-64), with no
instrumentation, and almost no messuring overhead. Of course this assumes
that call relationship is roughly the same for the same program with
different compilers/platforms.
BTW, has somebody used OProfile to profile valgrind?
If somebody is interested, I could provide some messurements.
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-25 08:43:23
|
On Wed, 24 Mar 2004, Josef Weidendorfer wrote:
> You are right. It's only a matter of writing a conversion script from massif
> data (raw/ASCII ?) to cachegrind/calltree format.
> KCachegrind should be able to cope with multiple cachegrind/calltree simple
> concatenated together (for multiple consensi). The format is described in a
> HTML documentation in the calltree package.
> Any volunteers?
I'm not sure about this. With (K)Cachegrind, you have a figure for every
instruction in the program, and these get mapped onto individual lines.
For Massif, you don't really have a spacetime figure for every
instruction. I think you'd only be annotating lines containing a function
call that allocates memory, or that (eventually) calls a function that
allocated memory? Eg, in this (nonsense) program:
int* f(void)
{
return malloc(1000); // 11 * 1000 * t
}
int* g(void)
{
bar();
for (i = 0; i < 10; i++)
f(); // 10 * 1000 * t
return f(); // 1 * 1000 * t
}
int* h(void)
{
foo();
x = y + z;
return g(); // 11 * 1000 * t
}
(where 't' is the length of time all the blocks are in existence for).
The comments show where the annotations would go; I'm assuming h() is
only called once.
Is that right?
N
|