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
(5) |
|
2
(2) |
3
(15) |
4
(3) |
5
|
6
(11) |
7
(4) |
8
|
|
9
(3) |
10
(6) |
11
(4) |
12
(5) |
13
(7) |
14
(37) |
15
(8) |
|
16
(1) |
17
(19) |
18
(20) |
19
(20) |
20
(15) |
21
(13) |
22
|
|
23
|
24
(20) |
25
(6) |
26
(2) |
27
(4) |
28
(6) |
29
|
|
30
(5) |
|
|
|
|
|
|
|
From: Avery P. <ape...@ni...> - 2003-11-02 20:20:41
|
On Sat, Nov 01, 2003 at 12:33:51PM +0000, Nicholas Nethercote wrote:
> Where did you insert the VALGRIND_MAKE_READABLE call? I'm pretty sure
> that macro will work on the stack. If I've understood your technique, I
> think you want to do this:
>
> remember esp
> alloc big new chunk on the stack
> restore esp
> call VALGRIND_MAKE_READABLE on the new chunk
>
> The critical thing being that you call the macro after you restore %esp.
Okay, so whatever I was doing before was definitely wrong, because I
followed this advice and stopped getting spurious valgrind errors. Yay!
Now, I think this disables a certain amount of valgrind checking. That is:
int x;
if (!setjmp)
longjmp(elsewhere)
// else someone longjmped back to me
VALGRIND_MAKE_READABLE(blah blah)
printf("x is now %d\n", x);
In this example, valgrind won't be able to discover that x was
uninitialized, since the memory was already marked readable to compensate
for it spuriously being marked *unreadable* earlier.
This actually doesn't bother me too much, because I expect to have rather
few errors with this problem: usually the function runs quite far before
doing the setjmp/longjmp, so 99% of the time it will have initialized the
variables by then anyway. Also, any functions I call from inside this one
will have valgrind do the right thing.
The inaccuracy, however, lies in throwing away data and then trying to
reconstruct it inaccurately.
Since I have total control over the setjmp/longjmp calls, would it be
possible to add a feature to valgrind like
if (!setjmp)
VALGRIND_STOP_INVALIDATING
longjmp(elsewhere)
// else someone longjmped back to me
VALGRIND_START_INVALIDATING
printf("x is now %d\n", x);
It would then need to be sure to invalidate only the areas between the old
and new stack pointer whenever %sp is changed (the normal way) rather than
blindly invalidating "everything under the current stack pointer."
This is pretty low priority, however. Thanks to your original message my
unit tests finally run under valgrind and I fixed two bugs last night thanks
to that.
Have fun,
Avery
P.S. Jeremy: I know the amount of stack usage by the kernel, signals, etc is
"undefined", but if you make the sub-stack big enough, all is mostly well.
sigaltstack() is probably a good idea though, you're right.
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 18:01:00
|
Hi, We Valgrind developers thought it would be a good idea to run a little survey about Valgrind, so that we can learn about you, our users. The survey is below, we'd appreciate it if you filled it out. Hopefully we can use the results to improve Valgrind. Please include any information you think relevant. And please forward this to any Valgrind users you know who aren't subscribe to the list, but may be willing to participate. Please send all replies to me, not to the list. I'll post a summary of the results some time, probably in the next week or so, depending on how many replies I get. N # Valgrind survey # # What project(s) do you use Valgrind and its skins for? (Feel free to # include information such as: number of programmers, programming # language, audience, etc.) # Please indicate what proportion of your total Valgrind use each skin # accounts for. Leave blank skins you never use. (Example: Memcheck # 80%, Addrcheck 10%, Cachegrind 10%) # - Memcheck (default skin) # - Addrcheck # - Cachegrind # - Calltree/KCachegrind # - Helgrind # - Massif # - Annelid # - Crocus # - VGProf # - Other # How often do you run Valgrind skins over your project(s)? Describe # how you do this, eg. manually, automatically with scripts, etc. # Have you used other tools that do similar things to some Valgrind # skins (eg. Purify, etc)? If so, how does Valgrind compare? # What are the best things about Valgrind and its skins? # What are the worst things about Valgrind and its skins? # Would you find it useful if Valgrind was available on other operating # systems? If so, which one(s)? # Would you find it useful if Valgrind was available on other # architectures? If so which one(s)? # Are you happy with the way Valgrind is developed, eg. with respect to # mailing lists, bug reporting, release frequency, etc? # Any other comments, suggestions? # Thank you for your time. |