|
From: Jeremy F. <je...@go...> - 2003-12-16 02:04:13
|
Hi all,
You may have seen some references to "full virtualization" (or FV). This
is the work I've been doing to restructure the way that Valgrind relates
to its client.
Currently, Valgrind relies on using LD_PRELOAD to hook itself into the
client early in its execution. This has several problems:
* It doesn't get in early enough, so some unknown amount of code
has run before Valgrind starts
* It relies on the dynamic linker, so it doesn't work for static
binaries
* Valgrind and the client share a dynamic linker, which means that
Valgrind can't use any standard libraries
* Client state and Valgrind state are intermingled in memory, so a
stray client memory write can cause Valgrind to crash or
misbehave
The FV changes remove all these limitations. Valgrind no longer relies
on the dynamic linker - it actually loads the client's ELF executable
itself, and starts it from the very first instruction under Valgrind
control.
It also means that there's a much stricter barrier between Valgrind and
the client, akin to the barrier between the kernel and user-space.
Valgrind's use of the dynamic linker, libraries, etc is completely
independent of the client's. In addition, the client address space is
self-contained, with Valgrind's memory near the top of the address
space. Valgrind takes advantage of that by generating bounds checks on
client memory accesses, so they are prohibited from going outside the
client address space (this is done with x86 segmentation, and so adds
little or no extra overhead).
All the client's address-space manipulation syscalls (mmap, shmat, brk,
etc) are vetted to make sure that they are constrained within the client
address space. Some special ioctls which can create mappings (like the
DRI ioctls) can create mappings outside the client address space, which
can cause problems (at the very least it will cause the client to take
an exception with --pointercheck=yes).
For users, there shouldn't be much in the way visible changes. Apart
from static executables working, the main visible difference is in the
valgrind command, which is now an executable rather than a script. It
supports all the same options, as well as the VALGRIND_OPTS environment
variable.
The changes are bigger for Valgrind developers. Over time, we can start
dissolving vg_mylibc.c, and use standard library functions instead. We
can also consider using new libraries and languages. There are now
fewer restrictions on programming within Valgrind; the main one is that
direct use of mmap/munmap/mprotect() is discouraged, because we need
still need to be careful about where things are placed in the address
space, and track where things are. VG_(mmap) does its own memory
placement algorithm so that Valgrind's mmaps don't accidentally appear
in the client address space. There are also a few extra VKI_MAP_* flags
to control various Valgrind-specific mmap behaviours.
For tool (aka skin) authors, there have been a few changes in the tool
interface. Within the core, the tool interface functions are all
defined in coregrind/toolfuncs.def, which is used to generate vg_skin.h
and other files. This cuts down on a lot of tedious typing whenever a
new tool interface is added or changed; the cost is that perl is now
required for building (as opposed to just running the regression tests).
The tool interface itself has been changed a bit:
The VG_DETERMINE_INTERFACE_VERSION macro now takes two
arguments: a pointer to the tools pre_clo_init function (which
need not have any particular name, and may be static; and the
tools requirements for shadow memory, expressed as a floating
point number which is the shadow:client memory ratio (so
addrcheck uses 1/8th the client memory in shadow memory, since
it uses one bit per byte; memcheck uses 9/8ths the client
memory, because it has 8 V bits and 1 A bit per byte).
All the SK_(track_*) functions have been renamed to
SK_(init_*). This is because all tool entrypoints can be
explicitly set with a corresponding SK_(init_*) function, rather
than relying on functions with special names (though the special
names still work). The intention of this is to move away from
special filenames, since it can be a bit fragile if the names
change (if you rename the function in the core without updating
the tool, then the tool may silently fail to work, rather than
alerting you to the rename at compile time).
There's a special area of memory for shadow data. As I
mentioned above, the tool's init now has to tell the core how
much shadow memory it wants to use. There are now two ways of
using shadow memory:
1. You can allocate page-sized chunks of the shadow memory
with VG_(shadow_alloc)(size). This just returns a
pointer to the next piece of free shadow memory. If it
runs out (ie, you ask for more shadow memory than you
said you would), it panics.
2. You can also treat all shadow memory as a big array.
This array is incrementally initialized as you touch
it. The first time you touch a particular shadow page,
it calls your SK_(init_shadow_page) function to
initialize that page. This is basically called from a
signal handler, so you have to be careful to keep this
function as simple as possible.
Shadow memory is from VG_(shadow_base)() to VG_(shadow_end)().
The tools are running in a very different context from the
client code. This means that if you want to override some
client functions, you can't just declare them and expect your
code to be run by the client. You need to create a separate .so
file for your tool, called vgpreload_TOOLNAME.so. If the core
sees this when it loads your tool, it also sets the client
environment up to LD_PRELOAD this into the client address
space. If you want to replace the malloc calls, you can also
link coregrind/vg_replace_malloc.o into your vgpreload_*.so
file.
Similarly, if you want to allocate something in the client
address space, you need to use VG_(cli_malloc/free). If you
pass a pointer to the client which is in the Valgrind address
space, it won't be able to dereference it. Similarly, you
cannot call code which is in the Valgrind core or tool from the
client - you must arrange for the code to be in the client
address space.
You can look at the changes to memcheck and addrcheck to see all of
these being put to use (well, not shadow memory as a virtual array). In
general it only takes a few minutes to update a tool to the new
interface.
I've updated all the standard tools, and they all seem to mostly work.
Cachegrind is having trouble with dlclose(), which I haven't
investigated yet.
Oh, and the --in-place=<path> command-line option has gone. Its
replacement is the VALGRINDLIB environment variable. The build process
creates a $topdir/.in_place directory which is populated with symlinks
to the newly built core and tools, so you can use 'VALGRINDLIB=.in_place
coregrind/valgrind ...' to run it in place.
I've been testing this pretty solidly for a while, so I think it should
work OK. No doubt you'll find some problems, but that's why I'm
checking it in (and why we did the 2.1.0 release *before* checking it in
- so that there's something semi-stable for people to play with).
J
|
|
From: John C. <joh...@ta...> - 2003-12-16 02:22:03
|
On Mon, 15 Dec 2003, Jeremy Fitzhardinge wrote: > * It relies on the dynamic linker, so it doesn't work for static > binaries Ooh! I love you! This means we will be able to use it on eCos synth target. (If you don't know eCos is an RTOS for embedded computers, it also has a version "synthetic" that allows you to develop, test and debug your embedded Application on your linux desktop.) Thus, by proxy, you have given the power of Valgrind to the many developers for many kinds of Arcane CPU's. Yahoooooooooooooooooooooo! John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand A Million Monkeys can inflict worse things than just Shakespeare on your system. |
|
From: Robert W. <rj...@du...> - 2003-12-16 06:02:25
|
> I've updated all the standard tools, and they all seem to mostly work.=20 > Cachegrind is having trouble with dlclose(), which I haven't > investigated yet. I'm seeing corecheck/tests/as_shm failing, too: *** as_shm.stdout.exp 2003-12-15 21:35:38.000000000 -0800 --- as_shm.stdout.out 2003-12-15 21:49:44.000000000 -0800 *************** *** 1 **** ! shmat 0: addr=3D0x81156000 --- 1 ---- ! shmat 0: addr=3D0x8101c000 Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Jeremy F. <je...@go...> - 2003-12-16 08:16:47
|
On Mon, 2003-12-15 at 22:02, Robert Walsh wrote: > > I've updated all the standard tools, and they all seem to mostly work. > > Cachegrind is having trouble with dlclose(), which I haven't > > investigated yet. > > I'm seeing corecheck/tests/as_shm failing, too: > > *** as_shm.stdout.exp 2003-12-15 21:35:38.000000000 -0800 > --- as_shm.stdout.out 2003-12-15 21:49:44.000000000 -0800 > *************** > *** 1 **** > ! shmat 0: addr=0x81156000 > --- 1 ---- > ! shmat 0: addr=0x8101c000 Yeah, that address depends on how big your libc and other libraries are, so it isn't the greatest test. J |
|
From: Tom H. <th...@cy...> - 2003-12-17 11:41:49
Attachments:
valgrind-beta-settidaddr-patch
|
In message <1071540160.20064.65.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> I've been testing this pretty solidly for a while, so I think it should
> work OK. No doubt you'll find some problems, but that's why I'm
> checking it in (and why we did the 2.1.0 release *before* checking it in
> - so that there's something semi-stable for people to play with).
I've just had a go with the CVS head, and I've found a couple of minor
issues with it:
With RH9 it was complaining about syscall 258 which is set_tid_address
which is called by ld.so early on, so valgrind never used to see it. A
patch to add support for this is attached.
Although simple programs worked, a debug build of one of our main
programs failed to mmap many of the shared objects. I managed to work
round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little
over 300Mb in size. Debug builds of our software are somewhat extreme
in their use of shared libraries - this program had about 150 or so
and they mostly had level 3 DWARF debugging on.
I noticed that if you track FD leaks then both /usr/bin/valgrind and
the client executable are reported as leaks.
Other than that it seems fine so far...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 00:27:49
|
On Thu, 2003-12-18 at 02:32, Tom Hughes wrote: > In message <yek...@au...> > Tom Hughes <th...@cy...> wrote: > > > In message <107...@ix...> > > Jeremy Fitzhardinge <je...@go...> wrote: > > > >> On Thu, 2003-12-18 at 00:24, Tom Hughes wrote: > > > >>> No. It was looking at the symbol tables and was managing to map about > >>> half the libraries then reporting mmap failed for the rest. As I increased > >>> that number it gradually reported fewer and fewer failures. > >> > >> Hm. I'm a bit confused. Can you look at what's mapped at the time it > >> fails? > > > > I'll have a look. > > You are quite right that none of our code is mapped in valgrind's part > of the address space when the mmap fails. They are mapped in the client > part of course, but that shouldn't matter. > > I stopped valgrind in the debugger at the point where the mmap has > just failed, and the resulting map is attached. The stack trace at > that point looks like this: Hm. There's two possibilities: one is that the mmap syscall itself failed; the other is that VG_(find_map_space) failed to return some space. Could you put some debug prints in there to see which case is occurring, and if its mmap, what the error return is? It seems there should be plenty of space in the address space for your mapping. J |
|
From: Julian S. <js...@ac...> - 2003-12-17 18:35:13
|
I'm experiencing some turbulence on SuSE 9. Running any program on memcheck, there are a lot more uninit-val errors reported than before. Even with 'ls'. Probably easier to track down, when running /opt/kde3/bin/kate on memcheck, there are also hundreds of messages like this: ==5883== Warning: invalid file descriptor 822 in syscall close() ==5883== at 0x3D505D71: close (in /lib/libc.so.6) ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&, char const*) (in /opt/kde3/lib/kde3/libkonsolepart.so) ==5883== by 0x3E1FD265: TEPty::commSetupDoneC() (in /opt/kde3/lib/kde3/ libkonsolepart.so ) running from fd=822 up to 1023. Sometimes it starts are 821 instead. Any ideas? J |
|
From: Tom H. <th...@cy...> - 2003-12-17 18:45:20
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Probably easier to track down, when running /opt/kde3/bin/kate on memcheck,
> there are also hundreds of messages like this:
>
> ==5883== Warning: invalid file descriptor 822 in syscall close()
> ==5883== at 0x3D505D71: close (in /lib/libc.so.6)
> ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&,
> char const*)
> (in /opt/kde3/lib/kde3/libkonsolepart.so)
> ==5883== by 0x3E1FD265: TEPty::commSetupDoneC() (in /opt/kde3/lib/kde3/
> libkonsolepart.so
> )
>
> running from fd=822 up to 1023. Sometimes it starts are 821 instead.
> Any ideas?
That's nothing to do with FV though is it? It looks more like something
that came from the syscall edits which cause FDs above about 822 to be
reserved for use by valgrind and that warning to be issued if the client
tries to do anything to them.
The problem is that some programs loop over all valid FDs and close
them when spawning a child or whatever, so you get that run of errors.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:09:50
|
On Wed, 2003-12-17 at 11:49, Julian Seward wrote: > I'm experiencing some turbulence on SuSE 9. > > Running any program on memcheck, there are a lot more uninit-val > errors reported than before. Even with 'ls'. Are the early? Are they in ld-linux.so? Are they str*() functions? > Probably easier to track down, when running /opt/kde3/bin/kate on memcheck, > there are also hundreds of messages like this: > > ==5883== Warning: invalid file descriptor 822 in syscall close() > ==5883== at 0x3D505D71: close (in /lib/libc.so.6) > ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&, > char const*) > (in /opt/kde3/lib/kde3/libkonsolepart.so) [...] > running from fd=822 up to 1023. Sometimes it starts are 821 instead. > Any ideas? As Tom said, this should occur in 2.1.0 as well - that's part of the syscalls changes. Maybe the trick would be to change the client's view of the soft (or hard) file-descriptor limit, in case they use that to work out what file-descriptors to close. Anyway, it's basically noise - maybe I shouldn't bother warning about those... J |
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:16:15
|
On Wed, 2003-12-17 at 11:49, Julian Seward wrote: > I'm experiencing some turbulence on SuSE 9. > > Running any program on memcheck, there are a lot more uninit-val > errors reported than before. Even with 'ls'. Actually, did you make sure the defaults.supp got rebuilt? It may be that your system needs some more glibc/ld.so suppressions, since we're now running earlier code than we ever did. J |
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:12:22
|
On Wed, 2003-12-17 at 03:41, Tom Hughes wrote: > With RH9 it was complaining about syscall 258 which is set_tid_address > which is called by ld.so early on, so valgrind never used to see it. A > patch to add support for this is attached. What does set_tid_address do again? It might be better to just silently fail it with ENOSYS since we're not doing anything useful with that stuff yet. > Although simple programs worked, a debug build of one of our main > programs failed to mmap many of the shared objects. I managed to work > round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little > over 300Mb in size. Debug builds of our software are somewhat extreme > in their use of shared libraries - this program had about 150 or so > and they mostly had level 3 DWARF debugging on. It should only be trying to map one of those in at once - do you really have a 100MByte+ .so file? > I noticed that if you track FD leaks then both /usr/bin/valgrind and > the client executable are reported as leaks. That shouldn't be. What fds is it finding them at? J |
|
From: Robert W. <rj...@du...> - 2003-12-18 01:32:38
|
> Probably easier to track down, when running /opt/kde3/bin/kate on memcheck, > there are also hundreds of messages like this: > > ==5883== Warning: invalid file descriptor 822 in syscall close() > ==5883== at 0x3D505D71: close (in /lib/libc.so.6) > ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&, > char const*) > (in /opt/kde3/lib/kde3/libkonsolepart.so) > ==5883== by 0x3E1FD265: TEPty::commSetupDoneC() (in /opt/kde3/lib/kde3/ > libkonsolepart.so > ) > > running from fd=822 up to 1023. Sometimes it starts are 821 instead. > Any ideas? Yup - Jeremy twiddled the fd tracking stuff to not record fds above 820. Unfortunately, he forgot to change the close stuff to ignore those, too... ;-) It's an easy fix. Regards, Robert. |
|
From: Jeremy F. <je...@go...> - 2003-12-18 02:03:48
|
On Wed, 2003-12-17 at 17:32, Robert Walsh wrote: > Yup - Jeremy twiddled the fd tracking stuff to not record fds above > 820. Unfortunately, he forgot to change the close stuff to ignore > those, too... ;-) It's an easy fix. I deliberately report when close() is being used with a bad fd - it can be a symptom of a program closing wild file-descriptors if the fd is bad. But the "loop over all fds and close them" idiom is pretty common too. Maybe yet another CLO? J |
|
From: Tom H. <th...@cy...> - 2003-12-18 08:24:44
|
In message <1071709848.16950.17.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Wed, 2003-12-17 at 03:41, Tom Hughes wrote:
>> With RH9 it was complaining about syscall 258 which is set_tid_address
>> which is called by ld.so early on, so valgrind never used to see it. A
>> patch to add support for this is attached.
>
> What does set_tid_address do again? It might be better to just silently
> fail it with ENOSYS since we're not doing anything useful with that
> stuff yet.
It gives the kernel a pointer to a pid_t which in which it should
store the current thread's tid whenever it feels like it. In this
case ld.so was actually passing NULL as the argument so it was in
fact turning off this functionality.
>> Although simple programs worked, a debug build of one of our main
>> programs failed to mmap many of the shared objects. I managed to work
>> round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little
>> over 300Mb in size. Debug builds of our software are somewhat extreme
>> in their use of shared libraries - this program had about 150 or so
>> and they mostly had level 3 DWARF debugging on.
>
> It should only be trying to map one of those in at once - do you really
> have a 100MByte+ .so file?
No. It was looking at the symbol tables and was managing to map about
half the libraries then reporting mmap failed for the rest. As I increased
that number it gradually reported fewer and fewer failures.
>> I noticed that if you track FD leaks then both /usr/bin/valgrind and
>> the client executable are reported as leaks.
>
> That shouldn't be. What fds is it finding them at?
At 4 and 5, after stdin/out/err and my valgrind log fd which is 3:
==23501== FILE DESCRIPTORS: 6 open at exit.
==23501== Open file descriptor 5: /usr/cqcs/V72X/cqcs/vcq
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 4: /usr/bin/valgrind
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 3: /home/thh/vg.out
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 2: /dev/pts/1
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 1: /dev/pts/1
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 0: /dev/pts/1
==23501== <inherited from parent>
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:03:40
|
On Thu, 2003-12-18 at 00:24, Tom Hughes wrote: > It gives the kernel a pointer to a pid_t which in which it should > store the current thread's tid whenever it feels like it. In this > case ld.so was actually passing NULL as the argument so it was in > fact turning off this functionality. So we can just ignore the syscall for now? > No. It was looking at the symbol tables and was managing to map about > half the libraries then reporting mmap failed for the rest. As I increased > that number it gradually reported fewer and fewer failures. Hm. I'm a bit confused. Can you look at what's mapped at the time it fails? > >> I noticed that if you track FD leaks then both /usr/bin/valgrind and > >> the client executable are reported as leaks. > > > > That shouldn't be. What fds is it finding them at? > > At 4 and 5, after stdin/out/err and my valgrind log fd which is 3: That was actually a bug in your patch to set VG_(max_fds) dynamically - it was trying to use VG_(safe_fd) before you'd initialized VG_(max_fds). I just checked in a fix. J |
|
From: Tom H. <th...@cy...> - 2003-12-18 10:05:10
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2003-12-18 at 00:24, Tom Hughes wrote:
>> It gives the kernel a pointer to a pid_t which in which it should
>> store the current thread's tid whenever it feels like it. In this
>> case ld.so was actually passing NULL as the argument so it was in
>> fact turning off this functionality.
>
> So we can just ignore the syscall for now?
I suspect so, because it seemed to work even though it printed a
warning about the unimplemented system call.
>> No. It was looking at the symbol tables and was managing to map about
>> half the libraries then reporting mmap failed for the rest. As I increased
>> that number it gradually reported fewer and fewer failures.
>
> Hm. I'm a bit confused. Can you look at what's mapped at the time it
> fails?
I'll have a look.
>> At 4 and 5, after stdin/out/err and my valgrind log fd which is 3:
>
> That was actually a bug in your patch to set VG_(max_fds) dynamically -
> it was trying to use VG_(safe_fd) before you'd initialized
> VG_(max_fds). I just checked in a fix.
Ah right. I'd forgotten I had some of my patches applied ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-12-18 17:10:32
Attachments:
valgrind-preload-patch
|
In message <1071540160.20064.65.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> I've been testing this pretty solidly for a while, so I think it should
> work OK. No doubt you'll find some problems, but that's why I'm
> checking it in (and why we did the 2.1.0 release *before* checking it in
> - so that there's something semi-stable for people to play with).
I've found another problem - if you fork and exec then it removes
the vg_inject.so entry from LD_PRELOAD but not any vgpreload_xxx.so
entry that the current tool may have added, so if you're using
memcheck you wind up with a very oddly broken malloc in the child
process ;-)
Attached is a patch to fix this.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 18:02:33
|
On Thu, 2003-12-18 at 09:09, Tom Hughes wrote: > Attached is a patch to fix this. Oops. Thanks. J |
|
From: Tom H. <th...@cy...> - 2003-12-19 07:19:05
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Hm. There's two possibilities: one is that the mmap syscall itself
> failed; the other is that VG_(find_map_space) failed to return some
> space. Could you put some debug prints in there to see which case is
> occurring, and if its mmap, what the error return is? It seems there
> should be plenty of space in the address space for your mapping.
It's the call to VG_(find_map_space) at the top of VG_(mmap) that
is failing.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 08:23:22
|
On Thu, 2003-12-18 at 23:19, Tom Hughes wrote: > In message <107...@ix...> > Jeremy Fitzhardinge <je...@go...> wrote: > > > Hm. There's two possibilities: one is that the mmap syscall itself > > failed; the other is that VG_(find_map_space) failed to return some > > space. Could you put some debug prints in there to see which case is > > occurring, and if its mmap, what the error return is? It seems there > > should be plenty of space in the address space for your mapping. > > It's the call to VG_(find_map_space) at the top of VG_(mmap) that > is failing. I wonder if it's getting confused by all the mmap/munmap calls. This should affect a client process which does lots of mmap/munmap calls too. I'll have a look. Could you file a bug? J |
|
From: Tom H. <th...@cy...> - 2003-12-19 09:27:31
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2003-12-18 at 23:19, Tom Hughes wrote:
>> In message <107...@ix...>
>> Jeremy Fitzhardinge <je...@go...> wrote:
>>
>> > Hm. There's two possibilities: one is that the mmap syscall itself
>> > failed; the other is that VG_(find_map_space) failed to return some
>> > space. Could you put some debug prints in there to see which case is
>> > occurring, and if its mmap, what the error return is? It seems there
>> > should be plenty of space in the address space for your mapping.
>>
>> It's the call to VG_(find_map_space) at the top of VG_(mmap) that
>> is failing.
>
> I wonder if it's getting confused by all the mmap/munmap calls. This
> should affect a client process which does lots of mmap/munmap calls
> too. I'll have a look. Could you file a bug?
Done as 70827.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|