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: Nicholas N. <nj...@ca...> - 2004-03-02 23:22:06
|
On Tue, 2 Mar 2004, Jeremy Fitzhardinge wrote: > Fix assertion failure when using VG_(system) near program termination. Ah, great! This fixes bugs.kde.org/show_bug.cgi?id=76004 for me. Thanks, Jeremy. N |
|
From: Doug R. <df...@nl...> - 2004-03-02 23:09:10
|
On Tue, 2004-03-02 at 22:08, Jeremy Fitzhardinge wrote: > On Tue, 2004-03-02 at 01:14, Doug Rabson wrote: > > I had another problem yesterday where layout_remaining_space was failing > > to mmap the redzone and the shadow map. I added yet another flag to > > VG_(mmap) to allow mapping the shadow area but it all starts to feel > > wrong. The other idea I had yesterday was to add a new flag, e.g. > > VKI_MAP_NOCHECKING. The mmap override would or this in to the flags > > passed to VG_(mmap) and that would turn off the client/valgrind address > > space checks. This would leave ume.c just using the plain standard mmap > > api. > > Hm, yes. For the sake of correctness, I think it is a good idea if > we're clear about the intent of each mmap(), and whether it should be > allowed to go into the client address space or not. If we're using > !MAP_FIXED, then it's obviously critical that it explicitly says which > address space it should go into. > > I was playing with having two flags rather than just one: > VKI_MAP_CLIENT, and VKI_MAP_VALGRIND (ie, all address space except the > client). This would allow us to say VG_(mmap)(..., > VKI_MAP_*|VKI_MAP_FIXED|VKI_MAP_CLIENT|VKI_MAP_VALGRIND,...), meaning > that we're OK with the mapping going into either address space, for the > use of ume.c. (We could make ume.c always use VG_(mmap) rather than > mmap, and provide an appropriate implementation for use in stage1.) I'm already doing something like this but I have problems with the bits of vg_main.c which map red-zones and the shadow area since the checking in VG_(mmap) is quite strict. |
|
From: Jeremy F. <je...@go...> - 2004-03-02 22:22:23
|
On Mon, 2004-03-01 at 17:15, Dirk Mueller wrote: > On Tuesday 02 March 2004 01:52, Jeremy Fitzhardinge wrote: > > > Yes. At the very least, stage1 needs to reserve the chunks of the > > address space needed for the client, before running the dynamic linker. > > Since the dynamic linker is unmodified glibc code, we can't control > > where it will place things, so we need to force its hand. > > Hmm, and why do we have to force it to place things in a certain way? Because the client address space is mapped 1:1 with the address space it would normally get without Valgrind (the difference is that it stops a bit short). FV creates a clear distinction between the client address space and Valgrind's address space, so that there's no scope for the client to start trashing Valgrind's memory. In order to achieve this, we need to make sure that all the pieces of Valgrind get placed outside the client address space (hence the need for the two-stage bootstrap). > > The other large mappings (like the shadow memory region) aren't really > > necessary, but they make inspecting things with /proc/<pid>/maps much > > easier. > > inspecting which kind of things ? Debugging Valgrind - for looking at the state of the address space as the program executes; in particular, you can see how shadow memory is being consumed. > > What's the purpose of your virtual limits. Is it to stop runaways, or > > actual malicious resource use? > > Well, both. it also helps debugging since you get a segfault instead of a > machine that swapped to death before you were able to attach a debugger. Well, in that case only setting the soft limit should be enough to prevent that failure. J |
|
From: Jeremy F. <je...@go...> - 2004-03-02 22:15:02
|
On Tue, 2004-03-02 at 01:14, Doug Rabson wrote: > I had another problem yesterday where layout_remaining_space was failing > to mmap the redzone and the shadow map. I added yet another flag to > VG_(mmap) to allow mapping the shadow area but it all starts to feel > wrong. The other idea I had yesterday was to add a new flag, e.g. > VKI_MAP_NOCHECKING. The mmap override would or this in to the flags > passed to VG_(mmap) and that would turn off the client/valgrind address > space checks. This would leave ume.c just using the plain standard mmap > api. Hm, yes. For the sake of correctness, I think it is a good idea if we're clear about the intent of each mmap(), and whether it should be allowed to go into the client address space or not. If we're using !MAP_FIXED, then it's obviously critical that it explicitly says which address space it should go into. I was playing with having two flags rather than just one: VKI_MAP_CLIENT, and VKI_MAP_VALGRIND (ie, all address space except the client). This would allow us to say VG_(mmap)(..., VKI_MAP_*|VKI_MAP_FIXED|VKI_MAP_CLIENT|VKI_MAP_VALGRIND,...), meaning that we're OK with the mapping going into either address space, for the use of ume.c. (We could make ume.c always use VG_(mmap) rather than mmap, and provide an appropriate implementation for use in stage1.) J |
|
From: Jeremy F. <je...@go...> - 2004-03-02 22:10:07
|
On Tue, 2004-03-02 at 01:53, Tom Hughes wrote: > This doesn't appear to work. I think the problem is that recent > versions of glibc will ignore AT_SYSINFO unless AT_SYSINFO_EHDR is > also set - maybe this is what bug 73891 is about? That would be annoying. I'm not really sure what to put for the ehdr. J |
|
From: Jeremy F. <je...@go...> - 2004-03-02 21:45:16
|
CVS commit by fitzhardinge:
Don't intercept mmap yet, until everything else is in place to deal
with it.
M +2 -0 vg_glibc.c 1.2
--- valgrind/coregrind/vg_glibc.c #1.1:1.2
@@ -34,6 +34,8 @@ void *sbrk(ptrdiff_t inc)
int __sbrk(void *) __attribute__((alias ("sbrk")));
+#if 0
void *mmap(void *addr, size_t len, int prot, int flags, int fd, __off_t offset)
{
return VG_(mmap)(addr, len, prot, flags, fd, offset);
}
+#endif
|
|
From: Jeremy F. <je...@go...> - 2004-03-02 21:44:09
|
CVS commit by fitzhardinge:
Fix assertion failure when using VG_(system) near program termination.
The problem is that the use of VG_(system) causes a SIGCHLD to be sent
to the process, which ends up being delivered to one of the proxy LWPs
(which is a small problem in itself, but nothing too bad).
The proxy tells the scheduler LWP about this, and the scheduler LWP sends
a sigACK reply.
Then, while the proxy LWP is in the SigACK state, and the SigACK reply
is still queued in the message pipe, the scheduler LWP starts shutting
Valgrind down, and sends a SIGVGKILL to all proxy LWPs. This causes
the proxy to drop from sigACK state to WaitReq state, and it reads
further commands - one of which is the SigACK message - this causes the
assertion failure.
The fix is to simply make the proxy LWP exit immediately when it gets
a SIGVGKILL, and not process any more requests.
This change also fixes a bug in VG_(system), in which the child process
returns back into Valgrind rather than exiting when exec fails.
M +3 -3 vg_mylibc.c 1.71
M +5 -4 vg_proxylwp.c 1.14
--- valgrind/coregrind/vg_mylibc.c #1.70:1.71
@@ -1626,8 +1626,8 @@ Int VG_(system) ( Char* cmd )
/* If we're still alive here, execve failed. */
- return -1;
+ VG_(exit)(1);
} else {
/* parent */
- res = VG_(do_syscall)(__NR_waitpid, pid, (UInt)NULL, 0);
+ res = VG_(waitpid)(pid, NULL, 0);
if (VG_(is_kerror)(res)) {
return -1;
--- valgrind/coregrind/vg_proxylwp.c #1.13:1.14
@@ -520,9 +520,10 @@ static Int proxylwp(void *v)
} else {
/* We got VKI_SIGVGKILL, which means we just skip all the
- below and get back to the state machine - probably to
- exit. */
+ below and exit. (Don't bother dealing with any pending
+ requests, because we'll probably just get confused.) */
px->state = PXS_WaitReq;
px->siginfo.si_signo = 0;
- goto state_machine;
+ ret = 0;
+ goto out;
}
@@ -629,5 +630,5 @@ static Int proxylwp(void *v)
}
- state_machine:
+ /* state_machine: */
px_printf("proxylwp main: state %s\n", pxs_name(px->state));
|
|
From: Tom H. <th...@cy...> - 2004-03-02 09:58:17
|
In message <1078090988.30493.70.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> Yes, that happens when you run under a kernel which doesn't have a
> sysinfo page. Normally, glibc will use the kernel's sysinfo, but if
> there isn't one, it uses _dl_sysinfo_int80. The FV loader will
> substitute the kernel's sysinfo page for its own, so that if your kernel
> supports sysinfo, Valgrind will do the right thing. The problem here is
> that it only substitutes an existing sysinfo page, but won't add an
> entry if there isn't one already. This means that glibc will use its
> own, and cause bogus traces like this.
Right.
> The fix is simple: add a sysinfo entry to the AUXV, even if there isn't
> one already.
This doesn't appear to work. I think the problem is that recent
versions of glibc will ignore AT_SYSINFO unless AT_SYSINFO_EHDR is
also set - maybe this is what bug 73891 is about?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-02 09:28:09
|
On Mon, 1 Mar 2004, Jeremy Fitzhardinge wrote: > > I think that nothing short of a full fork of Valgrind will do > > I get that feeling too. Same here. Not only does Windows have rather, er, interesting architectural features, you would be fighting its closedness the whole way. Sounds like a nightmare. N |
|
From: Doug R. <df...@nl...> - 2004-03-02 09:19:24
|
On Mon, 2004-03-01 at 23:55, Jeremy Fitzhardinge wrote: > On Mon, 2004-03-01 at 01:25, Doug Rabson wrote: > > 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. > > Yes, there's some tricky bootstrap stuff here. We should really try to > build the Segment list as soon as possible, so it's safe to use > VG_(mmap). > > > 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. > > That's a bit of a bug. vg_glibc.c shouldn't be redirecting mmap() to > VG_(mmap) yet for precisely this reason. I think Linux will complain if > it sees flags set it doesn't understand, so unconditionally or-ing in > VKI_CLIENT_MAP isn't going to work in general (and it only just barely > works in your case, because stage1's use of ume.c happens to link with > the plain old libc mmap, which presumably ignores VKI_MAP_CLIENT). The FreeBSD kernel seems to ignore the extra flags but its certainly not behaviour that we should rely on. > > > 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. > > Something like that. The goal is to make it so that libraries can use > brk and mmap freely, and they'll get results that will keep Valgrind > happy and sane. This means that we need to be sure that VG_(mmap) > changes operation mode between plain old kernel mmap and the internally > managed segment list mmap at precisely the right time, and that it > doesn't leave any valuable crud in the client address space early at the > start of time. > > This is all very fiddly. I had another problem yesterday where layout_remaining_space was failing to mmap the redzone and the shadow map. I added yet another flag to VG_(mmap) to allow mapping the shadow area but it all starts to feel wrong. The other idea I had yesterday was to add a new flag, e.g. VKI_MAP_NOCHECKING. The mmap override would or this in to the flags passed to VG_(mmap) and that would turn off the client/valgrind address space checks. This would leave ume.c just using the plain standard mmap api. |
|
From: Tom H. <to...@co...> - 2004-03-02 03:27:13
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-02 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 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) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-02 03:22:25
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-02 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, 2 stderr failures, 0 stdout failures ================= helgrind/tests/inherit (stderr) massif/tests/true_text (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-02 03:17:28
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-02 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-02 03:12:24
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-02 03:05:01 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, 12 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/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-02 03:10:57
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-02 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) make: *** [regtest] Error 1 |
|
From: Dirk M. <dm...@gm...> - 2004-03-02 01:20:10
|
On Tuesday 02 March 2004 01:52, Jeremy Fitzhardinge wrote: > Yes. At the very least, stage1 needs to reserve the chunks of the > address space needed for the client, before running the dynamic linker. > Since the dynamic linker is unmodified glibc code, we can't control > where it will place things, so we need to force its hand. Hmm, and why do we have to force it to place things in a certain way? > The other large mappings (like the shadow memory region) aren't really > necessary, but they make inspecting things with /proc/<pid>/maps much > easier. inspecting which kind of things ? > What's the purpose of your virtual limits. Is it to stop runaways, or > actual malicious resource use? Well, both. it also helps debugging since you get a segfault instead of a machine that swapped to death before you were able to attach a debugger. Dirk |
|
From: Jeremy F. <je...@go...> - 2004-03-02 00:58:53
|
On Mon, 2004-03-01 at 16:28, Dirk Mueller wrote: > On Tuesday 02 March 2004 00:53, Jeremy Fitzhardinge wrote: > > > Ah, OK. Does this help, or do you also set the hard limit? > > hard limit is set as well. do we really need that much mapped memory? Yes. At the very least, stage1 needs to reserve the chunks of the address space needed for the client, before running the dynamic linker. Since the dynamic linker is unmodified glibc code, we can't control where it will place things, so we need to force its hand. The other large mappings (like the shadow memory region) aren't really necessary, but they make inspecting things with /proc/<pid>/maps much easier. What's the purpose of your virtual limits. Is it to stop runaways, or actual malicious resource use? J |
|
From: Dirk M. <dm...@gm...> - 2004-03-02 00:33:31
|
On Tuesday 02 March 2004 00:53, Jeremy Fitzhardinge wrote: > Ah, OK. Does this help, or do you also set the hard limit? hard limit is set as well. do we really need that much mapped memory? Dirk |
|
From: Jeremy F. <je...@go...> - 2004-03-02 00:20:38
|
On Mon, 2004-03-01 at 15:36, KJK::Hyperion wrote: > 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: Well, the thing which Valgrind ideally wants is two complete address spaces: one for the client, and one for Valgrind. The idea is that the Valgrind should be able to control all the activity in the client address space, control execution, inject generated code, etc. We can't get that with the Unix memory model, but maybe we can use the (otherwise very painful) cross-address space features of Windows to get this effect. > - kernel32.dll: > [...] > - 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* Does this mean that if we translate this code into the instrumented code cache, then things will care because the EIP isn't within the kernel/user/gdi.dll? Also, is this code running in Ring 3, or a privileged level? > >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 I get that feeling too. J |
|
From: Jeremy F. <je...@go...> - 2004-03-02 00:02:12
|
On Mon, 2004-03-01 at 01:25, Doug Rabson wrote: > 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. Yes, there's some tricky bootstrap stuff here. We should really try to build the Segment list as soon as possible, so it's safe to use VG_(mmap). > 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. That's a bit of a bug. vg_glibc.c shouldn't be redirecting mmap() to VG_(mmap) yet for precisely this reason. I think Linux will complain if it sees flags set it doesn't understand, so unconditionally or-ing in VKI_CLIENT_MAP isn't going to work in general (and it only just barely works in your case, because stage1's use of ume.c happens to link with the plain old libc mmap, which presumably ignores VKI_MAP_CLIENT). > 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. Something like that. The goal is to make it so that libraries can use brk and mmap freely, and they'll get results that will keep Valgrind happy and sane. This means that we need to be sure that VG_(mmap) changes operation mode between plain old kernel mmap and the internally managed segment list mmap at precisely the right time, and that it doesn't leave any valuable crud in the client address space early at the start of time. This is all very fiddly. J |
|
From: Jeremy F. <je...@go...> - 2004-03-02 00:00:09
|
On Mon, 2004-03-01 at 05:14, Dirk Mueller wrote: > 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. Ah, OK. Does this help, or do you also set the hard limit? J |