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
(17) |
2
(21) |
3
(17) |
4
(28) |
5
(21) |
6
(11) |
|
7
(13) |
8
(21) |
9
(21) |
10
(9) |
11
(11) |
12
(15) |
13
(23) |
|
14
(15) |
15
(22) |
16
(28) |
17
(12) |
18
(15) |
19
(8) |
20
(7) |
|
21
(8) |
22
(12) |
23
(13) |
24
(7) |
25
(7) |
26
(3) |
27
(9) |
|
28
(13) |
29
(7) |
30
(7) |
31
(9) |
|
|
|
|
From: KJK::Hyperion <no...@li...> - 2004-03-01 23:39:28
|
At 20.37 01/03/2004, Chris January wrote:
>>My name is Rajesh and I am a student of Computer Sci in India. I want to
>>write a valgrind like utility for Windows. I know I sound silly but How
>>do I start? I am sorry if I am bothering u guys
>Ithink your main work will be in re-writing vg_mylibc.c and vg_syscalls.c.
>vg_mylibc.c is ok to re-write but for vg_syscalls.c you need to know all
>the Windows syscalls, what parameters they take, etc.
I've been thinking about Valgrind on Windows for a long time, and here's
the major stumbling blocks I've found:
- absolutely, completely forget full virtualization, i.e. loading the
target program in the same process as Valgrind. kernel32.dll, user32.dll
and gdi32.dll can only be loaded *once per process* and *at their default
base address*, and it's very impractical to write Valgrind tools without
using Win32 functions. In detail:
- kernel32.dll:
- once per process because once loaded it connects through LRPC to
the Win32 subsystem (winsrv.dll, running in the context of CSRSS). The
connection needs to be done because the subsystem won't accept calls from
unknown clients, and subsystem calls include the whole console API -
definitely something we want to support. And the connection can only be
done once per process because the process and thread ids are sent to the
subsystem at each call, and the subsystem not only keeps track of them
internally, but requires them to be valid process and thread ids, since it
will open them to perform operations. All of this is microkernel-era crap
that today is otherwise completely irrelevant, but we're stuck with it
- at the default base address to make CreateRemoteThread work.
CreateRemoteThread is used, among others, to signal processes attached to a
console that a control event (for example a Control-C) has been received
- user32.dll, gdi32.dll:
- once per process for reasons similar to kernel32.dll
- at the default base address for reasons you really don't want to
know. It has to do with the fact that the windowing system was ported from
Windows 95, where not only user32.dll and gdi32.dll were actually loaded at
the same address in all processes, but they were also loaded in *shared memory*
- liberal use of shared memory. It isn't uncommon for several processes
to share memory even with kernel mode code
- inter-process modifications. Nicholas told me this is going to be one
of the worst issues, as Valgrind currently assumes that near to no
interaction between unrelated processes is possible. On the other hand,
this kind of interactions is almost commonplace in Windows. Most can be
checked, as they happen at well-defined times (like passing buffers outside
the port section in LRPC calls), while others (like handle duplication) are
asyncronous and unpredictable. Some (like thread context changes) could
outright break Valgrind, altough they're hopefully rarely used
- I/O control operations. These are intrinsically problematic, and the
fact that many common IOCTLs (like the AFD IOCTLs, the default
implementation of TCP/IP for Winsock) aren't documented doesn't help a bit
>I have no idea what system calls are contained in the second table but i
>have seen some calls documented somewhere.
a crude listing of NtUserXxx and NtGdiXxx system calls can be obtained from
the debugging symbols of win32k.sys. Note that some NtUserXxx functions are
multiplexers, actually implementing several different calls each, and that
some others have unusual effects on the calling process (like mapping
several shared memory views) that can confuse Valgrind. Finally, an awful
lot of user32 functions aren't system calls, but they read into memory
shared with the kernel-mode windowing system (window and menu handles
aren't really handles, but decorated offsets into a table stored in said
shared memory). A strange example of such calls is GetWindowRect, which,
reading 64 bits at once, should be prone to race conditions on 32 bit
machines - and it indeed *is* vulnerable! One wonders how can such a f***ed
up windowing system work so well in practice
>I am willing to help you if you want.
count me in too, even if I think that nothing short of a full fork of
Valgrind will do
|
|
From: Chris J. <ch...@at...> - 2004-03-01 19:57:14
|
> Hi guys. > My name is Rajesh and I am a student of Computer Sci in India. I want to write a valgrind like utility for Windows. I know > I sound silly but How do I start? I am sorry if I am bothering u guys Further to my previous post you might find this website useful: http://razor.bindview.com/tools/desc/strace_readme.html Chris |
|
From: Chris J. <ch...@at...> - 2004-03-01 19:42:38
|
> Hi guys. > My name is Rajesh and I am a student of Computer Sci in India. I want to write a valgrind like utility for Windows. I know > I sound silly but How do I start? I am sorry if I am bothering u guys I think your main work will be in re-writing vg_mylibc.c and vg_syscalls.c. vg_mylibc.c is ok to re-write but for vg_syscalls.c you need to know all the Windows syscalls, what parameters they take, etc. Not all of these are documented but you can typically work out most of the parameters by disassembling the Nt* preamble for a Zw* system call. There are two main system call tables, one for the standard Zw* calls and another for GDI, etc. calls. I have no idea what system calls are contained in the second table but i have seen some calls documented somewhere. I am willing to help you if you want. I recommend you buy Windows NT/2000 Native API reference by Garry Nebbett. Chris |
|
From: Dirk M. <dm...@gm...> - 2004-03-01 13:18:55
|
On Monday 01 March 2004 09:05, Jeremy Fitzhardinge wrote: > Hm. A number of the mmap calls are failing. How much physical memory > and swap does this machine have? 1 GB / 1 GB. ulimit -v 650MB. > Is it stock 2.6.3? yes. Dirk |
|
From: Nicholas N. <nj...@ca...> - 2004-03-01 10:08:28
|
On Sun, 29 Feb 2004 sun...@t2... wrote: > I'm interested in writing a new skin around valgrind that will enable > comprehensive memory profiling. > > I haven't found many profiling tools, and one I found (MemProf) > crashes on our code. You could try Massif, the new heap-profiling tool that's included in Valgrind's CVS, and will be included in 2.1.1 when it comes out. Your idea of wrapping functions is interesting. Massif has some facilities for 'drilling down' through stack traces, and also ignoring certain functions that are just wrappers for malloc/new/new[]. Your scheme sounds more powerful in general, though. N |
|
From: Doug R. <df...@nl...> - 2004-03-01 09:30:07
|
On Mon, 2004-03-01 at 08:05, Jeremy Fitzhardinge wrote: > On Sun, 2004-02-29 at 19:34, Dirk Mueller wrote: > > On Saturday 28 February 2004 17:25, Nicholas Nethercote wrote: > > > > > - Dirk's ulimit problem: Dirk, did Jeremy's commit fix this? > > > > not for me. Now valgrind instantly segfaults on any application. the core file > > is of no use.. contains no useful information :( > > > > attaching a strace. I'm running kernel 2.6.3. Other setups not yet tested. > > Hm. A number of the mmap calls are failing. How much physical memory > and swap does this machine have? Is it stock 2.6.3? I've been spending some time this weekend merging with valgrind cvs and I've seen similar problems on FreeBSD. The two main problems I had were that the first call to malloc in valgrind (a result of loading .valgrindrc) wiped part of ld-elf.so (which was loaded at 0xb0000000) since find_map_space didn't yet have a proper map of the address space. I bodged this by changing info.map_base in stage1.c so that ld-elf.so loaded somewhere else. The next problem was that all the mmaps in load_client (actually mapelf) failed miserably. This was because they were all trying to map client space and they didn't include the VKI_MAP_CLIENT flag. I ended up or-ing in 0x80000000 in a few places in ume.c. Perhaps a simpler solution to both problems might be for VG_(mmap) to go straight through to mmap_inner and not check the flags if valgrind is still initialising. |
|
From: Nicholas N. <nj...@ca...> - 2004-03-01 08:31:51
|
CVS commit by nethercote:
Make vg_regtest return 1 if any tests fail. Useful for scripts that call it.
M +6 -0 vg_regtest.in 1.20
--- valgrind/tests/vg_regtest.in #1.19:1.20
@@ -385,4 +385,10 @@
summarise_results();
+if (0 == $num_failures{"stdout"} && 0 == $num_failures{"stderr"}) {
+ exit 0;
+} else {
+ exit 1;
+}
+
##--------------------------------------------------------------------##
##--- end vg_regtest ---##
|
|
From: Jeremy F. <je...@go...> - 2004-03-01 08:09:17
|
On Sun, 2004-02-29 at 19:34, Dirk Mueller wrote: > On Saturday 28 February 2004 17:25, Nicholas Nethercote wrote: > > > - Dirk's ulimit problem: Dirk, did Jeremy's commit fix this? > > not for me. Now valgrind instantly segfaults on any application. the core file > is of no use.. contains no useful information :( > > attaching a strace. I'm running kernel 2.6.3. Other setups not yet tested. Hm. A number of the mmap calls are failing. How much physical memory and swap does this machine have? Is it stock 2.6.3? J |
|
From: <js...@ac...> - 2004-03-01 04:11:02
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-03-01 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) |
|
From: <js...@ac...> - 2004-03-01 03:54:55
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-03-01 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) |
|
From: Dirk M. <dm...@gm...> - 2004-03-01 03:38:58
|
On Saturday 28 February 2004 17:25, Nicholas Nethercote wrote: > - Dirk's ulimit problem: Dirk, did Jeremy's commit fix this? not for me. Now valgrind instantly segfaults on any application. the core file is of no use.. contains no useful information :( attaching a strace. I'm running kernel 2.6.3. Other setups not yet tested. Dirk |
|
From: Dirk M. <mu...@kd...> - 2004-03-01 03:29:16
|
CVS commit by mueller: remove arch subdir for 2.1.1 release M +1 -1 Makefile.am 1.68 --- valgrind/coregrind/Makefile.am #1.67:1.68 @@ -1,4 +1,4 @@ -SUBDIRS = x86 demangle arch . docs +SUBDIRS = x86 demangle . docs add_includes = -I$(srcdir)/demangle -I$(top_srcdir)/include -I$(srcdir)/x86 |
|
From: Tom H. <to...@co...> - 2004-03-01 03:26:35
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-01 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 126 tests, 15 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) |
|
From: Tom H. <th...@cy...> - 2004-03-01 03:22:00
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-01 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 3 stderr failures, 0 stdout failures ================= corecheck/tests/pth_cancel2 (stderr) helgrind/tests/inherit (stderr) massif/tests/true_html (stderr) |
|
From: Tom H. <th...@cy...> - 2004-03-01 03:16:49
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-01 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) |
|
From: Tom H. <th...@cy...> - 2004-03-01 03:11:48
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-01 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 126 tests, 13 stderr failures, 3 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/res_search (stdout) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/malloc3 (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) |
|
From: Tom H. <th...@cy...> - 2004-03-01 03:10:17
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-01 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 12 stderr failures, 5 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/pth_cancel2 (stderr) corecheck/tests/pth_cvsimple (stdout) corecheck/tests/pth_cvsimple (stderr) corecheck/tests/pth_exit (stderr) corecheck/tests/res_search (stdout) helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/pth_blockedsig (stdout) none/tests/pth_blockedsig (stderr) none/tests/yield (stdout) none/tests/yield (stderr) |