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
|
3
|
4
|
5
(2) |
6
(1) |
7
|
8
|
|
9
(1) |
10
(1) |
11
|
12
|
13
|
14
(3) |
15
(4) |
|
16
(4) |
17
(2) |
18
(18) |
19
|
20
|
21
(7) |
22
|
|
23
(2) |
24
(3) |
25
(1) |
26
(5) |
27
(12) |
28
(1) |
29
(2) |
|
30
(4) |
31
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-09 16:37:11
|
On Fri, 7 Mar 2003, Josef Weidendorfer wrote:
> > Thinking about it some more, the only reason I can think of why valgrind
> > even needs its own malloc() is this:
Thinking more, another important reason is this: for memcheck/addrcheck,
having the redzones around malloc'd blocks allows them to catch
over/under-runs.
> As I see, a skin is able to implement it's own GLIBC wrapper functions, no
> matter if they are called malloc() or perhaps open(), simply by defining the
> function in the skin.
> This is simply another (but static) way of defining the behaviour of a skin.
> E.g. in vg_skin.h, do a
>
> #define REDIRECT1(fn,rType,pType1) \
> rType fn(pType1 p1) { return VG_(fn)(p1); }
>
> and in the skin, put
>
> REDIRECT1(malloc,void*,size_t)
>
> Of course it would be good to be able to check at runtime if the skin defined
> its own wrapper for a function: Use dlsym(RTLD_DEFAULT,"malloc") and check if
> the address is defined inside of the skin. You can issue a warning if no
> wrapper was defined when e.g. "new_mem_heap" is requested.
Well, dlsym() is not available for use within Valgrind, unless someone
implements VG_(dlsym)(). I think.
It's an interesting idea, but feels a bit messy to me... there's one more
thing for a skin to get wrong (ask for "new_mem_heap" but forget the
REDIRECT). Doing things statically with macros is a bit hacky too, but
maybe unavoidable.
But I do like the idea of the default behavour being "glibc malloc(), no
wrapper" and that a skin should have to request different behaviour...
kind of a "principle of least interference" with the original program.
It's worth thinking about the different possibilities here in more detail.
----
This is the sequence of events when a client calls malloc(), and
VG_(running_on_simd_CPU) == True.
1. client
- calls malloc()
2. vg_clientfuncs.c:malloc() wrapper is called:
- prints info, if --trace-malloc=yes
- checks arg, if negative:
- if core_checks needed, gives a warning
- returns NULL
- else calls SIMPLE_REQUEST1(VG_USERREQ__MALLOC, n)
3. vg_scheduler.c:do_client_request()
- calls VG_(client_malloc)()
4. vg_clientmalloc.c:VG_(client_malloc)():
- updates malloc stats (number of calls, bytes allocated)
- calls VG_(arena_malloc)()
- add a ShadowChunk (holding extra info about the block), if
needs_shadow_chunks is set
- calls new_mem_heap() event tracker, if there is one
(I don't understand why vg_clientfuncs.c:malloc() needs to use the client
request, rather than just calling VG_(client_malloc)() directly...
although when I tried it I got lots of "invalid read"s within
vg_malloc2.c only some programs... Julian?)
----
When must a skin use Valgrind's malloc?
- when red zones are needed
When must a skin use a malloc() wrapper?
- to print out debug info about malloc() calls
- if 'core_errors' is specified (it prints warning on negative args)
- to use new_mem_heap, etc
- to use ShadowChunks
Valgrind's own malloc() must of course still be used within the core.
What are the possible combinations:
a. no wrapper, glibc malloc()
b. no wrapper, valgrind malloc()
c. wrapper, glibc malloc()
d. wrapper, valgrind malloc
Memcheck would use (d), Helgrind would use (c) I think (doesn't need
redzones), Cachegrind & CallTree would use (a). No skins currently in
existence would use (b).
I think (c) can be achieved using ld's "--wrap symbol" option.
----
Here's my ideal scenario:
i. default is no wrapper + glibc malloc()
ii. skin can specify with a need if it wants to use Valgrind's malloc()
(eg. needs_redzones, or needs_special_malloc, or something)
iii. core decides whether a malloc() wrapper is needed (eg. because
new_mem_heap is being tracked, or --trace-malloc=yes is set, or
core errors or shadow chunks are needed
iv. if wrapper is needed, core calls glibc malloc() or Valgrind
malloc() depending on the needs_redzones/whatever need
I don't think all this is attainable. Esp (iii), since the conditions
there are all dynamic, but the overwriting by Valgrind of glibc's malloc()
symbol must be done statically.
I think wrapper + glibc() malloc might be attainable with the --wrap
linker option, but I'm not certain.
Josef, your REDIRECT idea is heading in the right direction, but not quite
there, I think.
----
So, lots of words from me, but no firm conclusions. Hmm.
N
|