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
(11) |
|
2
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-30 17:42:55
|
CVS commit by nethercote: Remove out-of-date limitations. M +0 -5 mc_techdocs.html 1.5.2.1 --- valgrind/memcheck/docs/mc_techdocs.html #1.5:1.5.2.1 @@ -466,9 +466,4 @@ <h3>Current limitations</h3> -No threads. I think fixing this is close to a research-grade problem. -<p> -No MMX. Fixing this should be relatively easy, using the same giant -trick used for x86 FPU instructions. See below. -<p> Support for weird (non-POSIX) signal stuff is patchy. Does anybody care? |
|
From: Nicholas N. <nj...@ca...> - 2003-11-30 17:42:23
|
CVS commit by nethercote: Remove out-of-date limitations from tech docs. M +0 -5 mc_techdocs.html 1.8 --- valgrind/memcheck/docs/mc_techdocs.html #1.7:1.8 @@ -466,9 +466,4 @@ <h3>Current limitations</h3> -No threads. I think fixing this is close to a research-grade problem. -<p> -No MMX. Fixing this should be relatively easy, using the same giant -trick used for x86 FPU instructions. See below. -<p> Support for weird (non-POSIX) signal stuff is patchy. Does anybody care? |
|
From: KJK::Hyperion <no...@li...> - 2003-11-30 15:10:44
|
At 13.10 29/11/2003, Nicholas Nethercote wrote: >>I subscribed this mailing list precisely to ask about a Windows port, but >>gave up temporarily when I read on the website about Valgrind's non >>existent support for multi-threaded processes >>Assuming this isn't true anymore, >Valgrind has supported multi-threaded processes for over a year now, maybe >even 18 months. this text in the technical overview is very misleading, then: >Threads >Doing a good job of thread support strikes me as almost a research-level >problem. The central issues are how to do fast cheap locking of the >VG_(primary_map) structure, whether or not accesses to the individual >secondary maps need locking, what race-condition issues result, and >whether the already-nasty mess that is the signal simulator needs further >hackery. > >I realise that threads are the most-frequently-requested feature, and I am >thinking about it all. If you have guru-level understanding of fast mutual >exclusion mechanisms and race conditions, I would be interested in hearing >from you. >>on Windows any process can modify any other process, given sufficient >>access to the target process object and related thread objects, and such >>modifications include allocating pages virtual memory, mapping pages of >>shared memory, writing ranges of memory, duplicating object handles, even >>altering the threads' contexts and LDTs. >Urgh... that sounds awful, like it would interact really badly with the >way Valgrind works. well, not that this kind of things happens normally. I think most inter-process memory writes happen either in a controlled way through the RPC system calls, and they're easily trackable, or through shared memory, something Valgrind wouldn't have much control on anyway. But you confirmed one of my fears. I guess I can lower the priority of a Valgrind port on my to-do list On a lighter note, Windows is very liberal about features and practices that would make any purist OS developer crazy. System calls, for example, use pointers passed by user-mode programs directly (after checking that the whole range is contained in user-mode memory, of course), with no explicit checking: access violations (segmentation faults) are handled in a manner similar to C++ exceptions, by unwinding the stack frames until the exception handler and setting the return value to the exception code. This isn't an implementation accident, but an explicit design feature: error codes and exception codes even share the same namespace (e.g. in UNIX you have EFAULT and SIGSEGV, while in Windows NT STATUS_ACCESS_VIOLATION covers both). You may also be surprised and outraged to discover that "statically linked" programs are impossible: as soon as a process is created, a special DLL (ntdll.dll) is injected into it, that contains the executable loader, the system call thunks and some runtime libraries (like the heap manager). Another cause of surprise and frustration is the area of memory shared between the kernel and every user-mode process: not a bad idea in itself (it lets you access the internal tick counter directly, discover the kernel version, and more), if only it wasn't loaded at a fixed address. In general, kernel-user interactions are often unorthodox and pretty extreme. The windowing system, for example, having been ported from a shared-memory system (think Windows 3.1), lets any client access its internal data structures (read-only, of course) - GDI handles, if any of you is familiar with them, aren't handles at all, but indexes in a huge array of GDI objects; same for window handles. Not to take up precious kernel virtual memory, the windowing system maps its shared data in write mode in a special process, and switches to its virtual address space whenever it needs to make any modification. And I think I already mentioned the kernel-mode threads you're free to create in any process >>This is the only real difficulty on Windows >Er, I think that might be understating things a bit. For example, I >imagine it would be much easier to port to a *nix OS than to Windows. hm, I don't know. How does Valgrind's memory checking work? does it keep a cache of the memory status somewhere? and the real memory of the process is kept in synch with the emulated memory? [ReactOS] >I had a look at that site. AFAICT, they started in 1997, and can now run >a few programs on NT 4.0. we can run a few Windows NT 4 *drivers*, please :-) >Sure, it is possible to find out about Windows internals, but a port to an >open-source OS would be *much* easier. I think that's not the major problem here. Let's say I am providing a precedent you can point people at (is this mailing list archived somewhere?) |