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
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2002-12-28 07:20:56
|
On Fri, 2002-12-27 at 21:36, Jeff Dike wrote: > je...@go... said: > > It seems to me that the correct check to apply is to see if there are > > already some valid/invalid addresses in that range; if so, this is a > > stack switch; if not, it is a stack extension/contraction. > > What happens if the memory in between is free? In the kernel, if the pages > in between the two stacks are free, then I have them marked as no-access, > and this would seem to trigger your stack expansion logic. So you mean the initial switch to a new stack from the stack which is immediately above it in memory? I don't think that will be a problem. Assuming you're talking about some kind of threading system, I think the creator of a thread will always allocate the memory for the new thread before starting it, which means that the bottom of the stack (uppermost addresses) will be made valid before the attempt to point %esp at it. After all, as Julian discovered, if you simply start accessing the new stack without any other preparation, and you have no stack size limit, the kernel will interpret that as a stack extension too. > ... and 5 seconds after posting my devastating critique of this plan, > I think of something which saves it ... > > And that is that there is always something at the bottom of a kernel > stack (a task_struct in 2.4, a thread_info in 2.5). This will be > marked valid, a stack switch will always jump over one, a stack > expansion never will, so at least in the kernel, this is a safe > heuristic. I actually think its always safe; I can't think of a reasonable usage which wouldn't trigger the test on a stack switch, for precisely this reason. Even if the threads system doesn't initialize the new thread stack with any data, the memory will have been at least allocated by the time of the first context switch to that thread. J |
|
From: Jeff D. <jd...@ka...> - 2002-12-28 05:37:49
|
je...@go... said: > It seems to me that the correct check to apply is to see if there are > already some valid/invalid addresses in that range; if so, this is a > stack switch; if not, it is a stack extension/contraction. ... and 5 seconds after posting my devastating critique of this plan, I think of something which saves it ... And that is that there is always something at the bottom of a kernel stack (a task_struct in 2.4, a thread_info in 2.5). This will be marked valid, a stack switch will always jump over one, a stack expansion never will, so at least in the kernel, this is a safe heuristic. Jeff |
|
From: Jeff D. <jd...@ka...> - 2002-12-28 05:33:20
|
je...@go... said: > It seems to me that the correct check to apply is to see if there are > already some valid/invalid addresses in that range; if so, this is a > stack switch; if not, it is a stack extension/contraction. What happens if the memory in between is free? In the kernel, if the pages in between the two stacks are free, then I have them marked as no-access, and this would seem to trigger your stack expansion logic. Jeff |
|
From: Jeremy F. <je...@go...> - 2002-12-28 04:44:49
|
Valgrind has a problem in being able to distinguish between large stack adjustments and stack switches. At the moment, the core has a heuristic based on the size of %esp delta. As shown by UML's use of stacks, this heuristic doesn't work reliably when you have a number of densely packed small stacks. It seems to me that the core can't really distinguish between these two types of esp updates. The only skins which really care about the distinction are memcheck and addrcheck, because they keep information about which parts of the address space are validly addressable, and which parts aren't. They can, however, use their address validity information to make the distinction between the two cases. When extending the stack, the effect is to increase the range valid addresses down from the old esp to the new esp; similarly, shrinking the stack invalidates the addresses between the old esp and the new esp. It seems to me that the correct check to apply is to see if there are already some valid/invalid addresses in that range; if so, this is a stack switch; if not, it is a stack extension/contraction. The rationale is that if one is apparently extending the stack over some already valid memory, it can't be an actual stack extension, because it means you're extending over some previously valid data structures. Similarly, a stack can't have invalid addresses embedded in it, so if there appear to be some, it is probably another stack. Of course, an actually buggy program which underflows or overflows its stack would incorrectly look like a stack switch, but with luck the other checking mechanisms would detect and report this as an error. J |