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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Sebastian K. <Seb...@so...> - 2003-04-18 13:13:11
|
From: "Jeremy Fitzhardinge" <je...@go...> > Thinking about it, I quite like Sebastian's idea of a > VALGRIND_STACK_SWITCH(thresh) call. This would mean "when you see a %esp > movement of at least threah bytes, that's a stack switch". This would be a > trigger thing, in that once the motion has been seen, future %esp changes are > seen as being within one stack until another call to VALGRIND_STACK_SWITCH. > > Note that if stacks are closely spaced, thresh would be considerably smaller than > the stack size (since going from a full stack adjacent empty stack just below > would be an %esp movement of less than a stack size - it could be arbitarily > small). Oh, thats the problem. But then, if we're already at placing hints in the source, then maybe another one: VALGRIND_REGISTER_STACK(adr, size) -- this would inform Valgrind that particular memory area is possibly going to become a separate stack at some time in the future. This would also work as invalidator for stack allocated from heap. To make stuff easier nagative value of size would mean that area is below (not above) adr, which could be sometimes more natural approach work stacks growing downwards. Then add VALGRIND_UNREGISTER_STACK(adr). rgds Sebastian Kaliszewski > > J > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <nj...@ca...> - 2003-04-18 12:55:11
|
On Fri, 18 Apr 2003, Olly Betts wrote: > > AC_PATH_PROG(GDB, gdb) > > AC_DEFINE(GDB_PATH, @GDB@, "gdb path") > > AC_SUBST(GDB) > > > > doesn't work cause configure don't do subsititution in > > config.h.in when creating config.h, I don't think there is > > any way to put it in config.h.in. > > There is - just use this: > > AC_PATH_PROG(GDB, gdb) > AC_DEFINE_UNQUOTED(GDB_PATH, "$GDB", "gdb with path") Ah, perfect, just what I wanted. I just committed the change. Thanks. N |
|
From: Olly B. <ol...@su...> - 2003-04-18 12:26:20
|
On Wed, Apr 16, 2003 at 07:00:05PM +0000, Philippe Elie wrote:
> Yes, it's a better way but the trivial:
>
> AC_PATH_PROG(GDB, gdb)
> AC_DEFINE(GDB_PATH, @GDB@, "gdb path")
> AC_SUBST(GDB)
>
> doesn't work cause configure don't do subsititution in
> config.h.in when creating config.h, I don't think there is
> any way to put it in config.h.in.
There is - just use this:
AC_PATH_PROG(GDB, gdb)
AC_DEFINE_UNQUOTED(GDB_PATH, "$GDB", "gdb with path")
Note that you must use AC_DEFINE_UNQUOTED instead of AC_DEFINE to get
$GDB expanded before it is substituted - otherwise config.h will
contain:
#define GDB_PATH "$GDB"
Cheers,
Olly
|
|
From: Jeremy F. <je...@go...> - 2003-04-18 09:40:55
|
Quoting Josef Weidendorfer <Jos...@in...>: > On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote: > > ... > > I think the correct solution is to move stack switch detection into > the > > skin themselves (memcheck, addrcheck and helgrind are the only ones I > know > > of which care). Memcheck and addrcheck can use their existing > validity > > info to make the determination; helgrind is harder. > > Calltree does ESP tracking, too. Needed for recursion detection and > correct > handling of setjmp/longjmp or C++ exceptions and like that. > > So I'm voting for a skin trackable event for stack switching from the > core. > Isn't this almost the same as the "switch_thread" event? > As I see, the first stack switch always has quite a large delta. If we switch_thread is a clear event which the scheduler knows about. A change of value in %esp can mean one of two things, and there's no way of really telling what it means without some heuristics. The heuristics we have at present get it wrong too often, with very bad results. > Doesn't the kernel need to know about stack segments somehow by > declaring the > VMA as growable? So isn't it enough to check for ESP changes among > growable > VMAs? > Or how behaves the LWP lib of AFS on stack overflows? If it uses > mprotect() > for manual stack growing, we can track this, too. The kernel only grows the main stack, not thread stacks; thread stacks are generally never growable. Thinking about it, I quite like Sebastian's idea of a VALGRIND_STACK_SWITCH(thresh) call. This would mean "when you see a %esp movement of at least threah bytes, that's a stack switch". This would be a trigger thing, in that once the motion has been seen, future %esp changes are seen as being within one stack until another call to VALGRIND_STACK_SWITCH. Note that if stacks are closely spaced, thresh would be considerably smaller than the stack size (since going from a full stack adjacent empty stack just below would be an %esp movement of less than a stack size - it could be arbitarily small). J |
|
From: Jeremy F. <je...@go...> - 2003-04-18 09:29:17
|
Quoting Nicholas Nethercote <nj...@ca...>: > Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, > and > within that look for a "sizeable" %esp change (eg. anything bigger > than > 1KB or something) as a genuine switch? Or maybe not, I don't know. Tricky if the context switch is performed by an instruction which both changes %esp and %eip (ie, leave). There would be no way to place the "after" annotation. > > > I think the correct solution is to move stack switch detection into > the skin > > themselves (memcheck, addrcheck and helgrind are the only ones I know > of which > > care). Memcheck and addrcheck can use their existing validity info to > make the > > determination; helgrind is harder. > > How does validity info help? Basically, if you're extending the stack over some already-valid memory, it means you're switching to a new stack at a lower address (since the valid memory is one or more intermediate stacks, or some other allocated memory); if you're shrinking the stack over some already-invalid memory, you're actually switching to a stack with a higher address. The only case where I can think of this failing is if your current stack has another stack just above it which has grown to touch/overlap this stack, and you context switch to it. But if that has happened, you've already got into deep trouble. Hm, now that I think about it, it doesn't really work that well when the stacks are in heap memory. But then, how well does V cope with that anyway? Wouldn't it allow access below %esp? J |