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