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
(4) |
3
(3) |
4
(6) |
5
(14) |
6
(10) |
7
(4) |
|
8
(2) |
9
(4) |
10
(7) |
11
(8) |
12
(5) |
13
(11) |
14
(4) |
|
15
(4) |
16
(9) |
17
(6) |
18
|
19
|
20
|
21
|
|
22
(3) |
23
(1) |
24
(7) |
25
(12) |
26
(8) |
27
(13) |
28
(4) |
|
29
(3) |
30
(4) |
|
|
|
|
|
|
From: Nir T. <nir...@gm...> - 2009-11-30 12:55:37
|
On Mon, Nov 30, 2009 at 2:49 PM, Josef Weidendorfer <Jos...@gm...> wrote: > Am Sonntag 29 November 2009 09:20:14 schrieb Nir Tzachar: >> Hello. >> >> I have been using valgrind for a very long time, and found it one of >> the best (if not The Best) debugging and bug finding tools ever. I >> have even ported applications from other archs to linux just to be >> able to run them through valgrind and track an elusive bug. >> >> However, there is one point where valgrind does not scratch my itch: >> reporting memory allocations. I have searched through the >> documentation, and did not find any way to report all the locations >> where memory is allocated. > > Sorry for my blatant ignorance for your use case. > What are the features missing from, e.g. massif, to fit your needs? Well, I do not care about the _total_ memory consumption, just the allocations themselves. Usually, I use memory pools, and just allocate from them. I do not care if they are large (I do, but this is another issue), but that _all_ code paths really use the pools and do not hide any unknown allocation behind the scenes. If massif can just report where ALL allocations are taking place and be able to suppress some of them, I would be a happy camper ;) |
|
From: Josef W. <Jos...@gm...> - 2009-11-30 12:50:45
|
Am Sonntag 29 November 2009 09:20:14 schrieb Nir Tzachar: > Hello. > > I have been using valgrind for a very long time, and found it one of > the best (if not The Best) debugging and bug finding tools ever. I > have even ported applications from other archs to linux just to be > able to run them through valgrind and track an elusive bug. > > However, there is one point where valgrind does not scratch my itch: > reporting memory allocations. I have searched through the > documentation, and did not find any way to report all the locations > where memory is allocated. Sorry for my blatant ignorance for your use case. What are the features missing from, e.g. massif, to fit your needs? Josef |
|
From: <sv...@va...> - 2009-11-30 09:06:09
|
Author: sewardj
Date: 2009-11-30 09:05:50 +0000 (Mon, 30 Nov 2009)
New Revision: 10959
Log:
On ARM, change the hash function for the fast translation table so
that we can use all of the entries instead of only 1/4 of them.
Modified:
branches/ARM/coregrind/m_dispatch/dispatch-arm-linux.S
branches/ARM/coregrind/pub_core_transtab_asm.h
Modified: branches/ARM/coregrind/m_dispatch/dispatch-arm-linux.S
===================================================================
--- branches/ARM/coregrind/m_dispatch/dispatch-arm-linux.S 2009-11-27 10:08:49 UTC (rev 10958)
+++ branches/ARM/coregrind/m_dispatch/dispatch-arm-linux.S 2009-11-30 09:05:50 UTC (rev 10959)
@@ -97,7 +97,7 @@
/* try a fast lookup in the translation cache */
// r0 = next guest, r1,r2,r3 scratch
ldr r1, =VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
- and r2, r1, r0 // r2 = entry #
+ and r2, r1, r0, LSR #2 // r2 = entry #
ldr r1, =VG_(tt_fast) // r1 = &tt_fast[0]
add r1, r1, r2, LSL #3 // r1 = &tt_fast[entry#]
ldr r3, [r1, #0] /* .guest */
@@ -142,7 +142,7 @@
/* try a fast lookup in the translation cache */
// r0 = next guest, r1,r2,r3 scratch
ldr r1, =VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
- and r2, r1, r0 // r2 = entry #
+ and r2, r1, r0, LSR #2 // r2 = entry #
ldr r1, =VG_(tt_fast) // r1 = &tt_fast[0]
add r1, r1, r2, LSL #3 // r1 = &tt_fast[entry#]
ldr r3, [r1, #0] /* .guest */
Modified: branches/ARM/coregrind/pub_core_transtab_asm.h
===================================================================
--- branches/ARM/coregrind/pub_core_transtab_asm.h 2009-11-27 10:08:49 UTC (rev 10958)
+++ branches/ARM/coregrind/pub_core_transtab_asm.h 2009-11-30 09:05:50 UTC (rev 10959)
@@ -40,17 +40,20 @@
On ppc32/ppc64, the bottom two bits of instruction addresses are
zero, which means that function causes only 1/4 of the entries to
ever be used. So instead the function is '(address >>u
- 2)[VG_TT_FAST_BITS-1 : 0]' on those targets. */
+ 2)[VG_TT_FAST_BITS-1 : 0]' on those targets.
+ On ARM we do like ppc32/ppc64, although that will have to be
+ revisited when we come to implement Thumb. */
+
#define VG_TT_FAST_BITS 15
#define VG_TT_FAST_SIZE (1 << VG_TT_FAST_BITS)
#define VG_TT_FAST_MASK ((VG_TT_FAST_SIZE) - 1)
/* This macro isn't usable in asm land; nevertheless this seems
like a good place to put it. */
-#if defined(VGA_x86) || defined(VGA_amd64) || defined(VGA_arm)
+#if defined(VGA_x86) || defined(VGA_amd64)
# define VG_TT_FAST_HASH(_addr) ((((UWord)(_addr)) ) & VG_TT_FAST_MASK)
-#elif defined(VGA_ppc32) || defined(VGA_ppc64)
+#elif defined(VGA_ppc32) || defined(VGA_ppc64) || defined(VGA_arm)
# define VG_TT_FAST_HASH(_addr) ((((UWord)(_addr)) >> 2) & VG_TT_FAST_MASK)
#else
# error "VG_TT_FAST_HASH: unknown platform"
|
|
From: Nir T. <nir...@gm...> - 2009-11-30 05:33:30
|
On Sun, Nov 29, 2009 at 9:06 PM, John Reiser <jr...@bi...> wrote:
>> ... any way to report all the locations
>> where memory is allocated. ...
>
> A static list of all the locations that _can_ allocate memory
> is useful, especially for an embedded environment ("If any location
> _can_ allocate memory, then eventually it _will_, often when memory
> is least available.")
>
> A pipeline such as this will identify all the compilation units
> with calls to alloc or new:
> nm -gop $(find . -name '*.[oa]') | grep -E 'alloc|new'
>
> A pipeline such as this will identify the locations of calls
> to alloc or new:
> readelf --relocs $(find . -name '*.o') | grep -E 'alloc|new'
>
> You may wish to insert " | c++filt " into the pipeline
> to demangle subroutine names. Also 'addr2line' can help
> identify line numbers.
This is a great suggestion, and will work spectacularly for plain C
code. However, for C++ code, you will generally need the entire call
graph to understand where the allocation comes from. Consider the
following simple example:
#include <iostream>
#include <vector>
std::vector<int> goo()
{
std::vector<int> vec;
vec.push_back(1);
return vec;
}
int main()
{
std::vector<int> vec = goo();
std::cout << vec.front() << std::endl;
return 0;
}
and then:
> nm -gop test | grep -E 'alloc|new' | c++filt
test:000000000040107c W
__gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long)
test:0000000000400da8 W __gnu_cxx::new_allocator<int>::~new_allocator()
test:000000000040109c W std::_Vector_base<int, std::allocator<int>
>::_M_deallocate(int*, unsigned long)
test:0000000000400e48 W std::_Vector_base<int, std::allocator<int>
>::_M_get_Tp_allocator()
test:0000000000400de2 W
__gnu_cxx::new_allocator<int>::new_allocator(__gnu_cxx::new_allocator<int>
const&)
test: U std::__throw_bad_alloc()@@GLIBCXX_3.4
test:0000000000400ebc W std::_Vector_base<int, std::allocator<int>
>::_M_get_Tp_allocator() const
test:0000000000400e56 W __gnu_cxx::new_allocator<int>::construct(int*,
int const&)
test:0000000000401406 W std::_Vector_base<int, std::allocator<int>
>::_M_allocate(unsigned long)
test:0000000000401048 W __gnu_cxx::new_allocator<int>::max_size() const
test:00000000004013bc W
__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)
test:0000000000400d86 W __gnu_cxx::new_allocator<int>::new_allocator()
not much info there, except that some allocations are related to
vectors. And believe me, when you start using some of the frameworks
in boost, you will be at a total loss, especially if the code you are
inspecting is not your own...
Your point of view can also be applied as to why do we need callgrind,
when we can perform a static analysis of our code, which will give us
the same results? Because it is much harder to do so (and even
impossible in some cases).
Cheers,
Nir.
|