[Valgrind-users] shmat calls fails with "invalid argument" under valgrind?

[Jeroen Janssen]

Hello,

I'm trying to run a program that uses shmat (fox example, the valgrind
test program as_shm in corecheck\tests).

However, I get a valgrind warning and an "Invalid argument" error
stopping the program.
See below for the valgrind output:

==6928== Coregrind, a rudimentary error detector for x86-linux.
==6928== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==6928== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==6928== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==6928== For more details, rerun with: -v
==6928==
shmat 0: addr=...
==6928== Warning: client syscall shmat tried to modify addresses
0xB0000000-0xB0010000
shmat @ top: Invalid argument
==6928==
==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Note that I'm running Suse-9.1.

Does this problem sound familiar to anyone? (I think this might look
like http://bugs.kde.org/show_bug.cgi?id=79282 but that should have
already been solved I think).

Best regards,

Jeroen Janssen

[Tom Hughes]

Post by Jeroen Janssen
==6928== Coregrind, a rudimentary error detector for x86-linux.
==6928== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==6928== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==6928== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==6928== For more details, rerun with: -v
==6928==
shmat 0: addr=...
==6928== Warning: client syscall shmat tried to modify addresses
0xB0000000-0xB0010000
==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.

Post by Jeroen Janssen
Does this problem sound familiar to anyone? (I think this might look
like http://bugs.kde.org/show_bug.cgi?id=79282 but that should have
already been solved I think).

It is the same as that bug, but that bug is not solved as such - it
was closed as INVALID because there is nothing we can do.

Tom

[Jeroen Janssen]

Post by Tom Hughes

Post by Jeroen Janssen
==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

[Nicholas Nethercote]

Post by Jeroen Janssen
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.

Post by Jeroen Janssen
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

[Tom Hughes]

Post by Jeroen Janssen

Post by Tom Hughes

Post by Jeroen Janssen
==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.

Post by Jeroen Janssen
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

[Nicholas Nethercote]

That's a much better explanation... ignore mine; I forgot to mention
shadow memory at all.

N