|
From: Jeroen J. <jer...@gm...> - 2004-11-11 11:54:06
|
>> ==6928== Warning: client syscall shmat tried to modify addresses >> 0xB0000000-0xB0010000 >> shmat <at> top: Invalid argument >> ==6928== >> ==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > >You're trying to attach a shared memory segment at an address that is >in the part of the address space that valgrind reserves to itself. This >won't work. Ok, that makes sense.. Is there an overview of the address space that is available/used under valgrind? Btw, note that the program run above is a test program of valgrind itself, maybe it can also be 'fixed' to use a "(valgrind) correct" shared memory segment? --- Jeroen Janssen |
|
From: Nicholas N. <nj...@ca...> - 2004-11-11 12:22:03
|
On Thu, 11 Nov 2004, Jeroen Janssen wrote: > Ok, that makes sense.. Is there an overview of the address space that > is available/used under valgrind? In 2.2.0, the client gets 0x0..0xafffffff, Valgrind gets 0xb0000000..0xbfffffff, the kernel gets 0xc0000000..0xffffffff. In the CVS version, if your system supports position-independent executables, valgrind uses (S-0x10000000)..(S-1), where S is the start of the kernel's memory (usually 0xc0000000, but can be different, even 0xffffffff on some systems. > Btw, note that the program run above is a test program of valgrind > itself, maybe it can also be 'fixed' to use a "(valgrind) correct" > shared memory segment? I'm not sure what you mean, but the test may well be deliberately asking for something that Valgrind cannot provide. N |
|
From: Tom H. <th...@cy...> - 2004-11-11 12:36:12
|
In message <e34...@ma...>
Jeroen Janssen <jer...@gm...> wrote:
>>> ==6928== Warning: client syscall shmat tried to modify addresses
>>> 0xB0000000-0xB0010000
>>> shmat <at> top: Invalid argument
>>> ==6928==
>>> ==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>>
>>You're trying to attach a shared memory segment at an address that is
>>in the part of the address space that valgrind reserves to itself. This
>>won't work.
>
> Ok, that makes sense.. Is there an overview of the address space that
> is available/used under valgrind?
Not really, and it isn't even fixed in the current CVS code as we now
try and load as high up as possible on systems which support position
independent executables. It will also depend on what tool you are using.
Broadly speaking the memory map under valgrind looks like this:
CLIENT_BASE +-------------------------+
| client address space |
: :
: :
| client stack |
client_end +-------------------------+
| redzone |
shadow_base +-------------------------+
| |
: shadow memory for tools :
| (may be 0 sized) |
shadow_end +-------------------------+
valgrind_base +-------------------------+
| kickstart executable |
| valgrind heap vvvvvvvvv| (barely used)
- -
| valgrind .so files |
| and mappings |
- -
| valgrind stack ^^^^^^^^^|
valgrind_last +-------------------------+
: kernel :
The exact position of the boundaries is variable however - the amount
of shadow space will depend on the tool for example. Plus the position
of the final boundary depends on how your kernel was built and how
much space it wants.
In 2.2.0 the value of valgrind_base is fixed based on the assumption
that you have a 3G+1G configuration with 1G of kernel space and 2G of
user space.
The CVS code now tries to adjust valgrind_base based on what the
kernel configuration is and hence where valgrind_last is.
> Btw, note that the program run above is a test program of valgrind
> itself, maybe it can also be 'fixed' to use a "(valgrind) correct"
> shared memory segment?
It does, or at least should do. It seems to work on all my systems.
What version of valgrind are you using when it fails?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-11 12:39:26
|
On Thu, 11 Nov 2004, Tom Hughes wrote: > Broadly speaking the memory map under valgrind looks like this: That's a much better explanation... ignore mine; I forgot to mention shadow memory at all. N |