|
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. |