From: David Schwartz on
On Sep 9, 8:47 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:

> But all of this is actually completely besides the point, because the
> library doesn't use MAP_FIXED. According to the comments in
>
>         valgrind-3.4.1/coregrind/m_aspacemgr/aspacemgr-linux.c
>
> this is supposed to work such that either the 'hinted' mapping is
> placed at the intended address (by the kernel) or that valgrind picks
> a suitable replacement address. The file linked-to by the OP doesn't
> contain MAP_FIXED, either.

I think you're drawing a distinction between the library and the
program that I'm not. In any event, I'm a bit confused now. The OP
specifically stated that an mmap call with MAP_FIXED was failing, and
that it was used in a case where it is not guaranteed to succeed. If
the library doesn't call mmap with MAP_FIXED and the program doesn't,
why is mmap getting called with MAP_FIXED? If valgrind is doing it, it
would be interesting to know the circumstances -- you may be right, it
maybe be a bug in valgrind.

DS
From: Moi on
On Thu, 10 Sep 2009 05:24:47 -0700, David Schwartz wrote:

> On Sep 9, 8:47 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>
>> But all of this is actually completely besides the point, because the
>> library doesn't use MAP_FIXED. According to the comments in
>>
>>         valgrind-3.4.1/coregrind/m_aspacemgr/aspacemgr-linux.c
>>
>> this is supposed to work such that either the 'hinted' mapping is
>> placed at the intended address (by the kernel) or that valgrind picks a
>> suitable replacement address. The file linked-to by the OP doesn't
>> contain MAP_FIXED, either.
>
> I think you're drawing a distinction between the library and the program
> that I'm not. In any event, I'm a bit confused now. The OP specifically
> stated that an mmap call with MAP_FIXED was failing, and that it was
> used in a case where it is not guaranteed to succeed. If the library
> doesn't call mmap with MAP_FIXED and the program doesn't, why is mmap
> getting called with MAP_FIXED? If valgrind is doing it, it would be
> interesting to know the circumstances -- you may be right, it maybe be a
> bug in valgrind.

relevant part of post++

.....

file_header hdr;
hdr.base_address = base;
hdr.file_size = 0;
read(fd, &hdr, sizeof hdr);
base = (char*)hdr.base_address;
allocated_size = size = ALIGN(hdr.file_size, page_size);
mapped_size = size > max_file_size ? size : max_file_size;
void* p = mmap(base, mapped_size, PROT_READ|PROT_WRITE,
MAP_VARIABLE|MAP_SHARED|MAP_FILE, fd, 0);
if (p == (char*)MAP_FAILED) {
error_code = errno;
TRACE_MSG(("post_file::open: mmap failed: base=%p, size=%ld: %
s\n",
base, mapped_size, strerror(error_code)));
::close(fd);
return false;
}
base = (char*)p;
n_locked_pages = 0;

....
, so it reads the intended map addres and size from the file before
mapping it to that "fixed" address.
Both of these _could_ of course contain garbage, causing EINVAL.

AvK

From: Rainer Weikusat on
Moi <root(a)invalid.address.org> writes:
> On Thu, 10 Sep 2009 05:24:47 -0700, David Schwartz wrote:
>> On Sep 9, 8:47�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>>
>>> But all of this is actually completely besides the point, because the
>>> library doesn't use MAP_FIXED. According to the comments in
>>>
>>> � � � � valgrind-3.4.1/coregrind/m_aspacemgr/aspacemgr-linux.c
>>>
>>> this is supposed to work such that either the 'hinted' mapping is
>>> placed at the intended address (by the kernel) or that valgrind picks a
>>> suitable replacement address. The file linked-to by the OP doesn't
>>> contain MAP_FIXED, either.
>>
>> I think you're drawing a distinction between the library and the program
>> that I'm not. In any event, I'm a bit confused now. The OP specifically
>> stated that an mmap call with MAP_FIXED was failing, and that it was
>> used in a case where it is not guaranteed to succeed. If the library
>> doesn't call mmap with MAP_FIXED and the program doesn't, why is mmap
>> getting called with MAP_FIXED? If valgrind is doing it, it would be
>> interesting to know the circumstances -- you may be right, it maybe be a
>> bug in valgrind.
>
> relevant part of post++
>
> ....
>
> file_header hdr;
> hdr.base_address = base;
> hdr.file_size = 0;
> read(fd, &hdr, sizeof hdr);
> base = (char*)hdr.base_address;
> allocated_size = size = ALIGN(hdr.file_size, page_size);
> mapped_size = size > max_file_size ? size : max_file_size;
> void* p = mmap(base, mapped_size, PROT_READ|PROT_WRITE,
> MAP_VARIABLE|MAP_SHARED|MAP_FILE, fd, 0);
> if (p == (char*)MAP_FAILED) {
> error_code = errno;
> TRACE_MSG(("post_file::open: mmap failed: base=%p, size=%ld: %
> s\n",
> base, mapped_size, strerror(error_code)));
> ::close(fd);
> return false;
> }
> base = (char*)p;
> n_locked_pages = 0;
>
> ...
> , so it reads the intended map addres and size from the file before
> mapping it to that "fixed" address.

This isn't a mapping to a fixed address, for the simple reason that
MAP_FIXED is not among the MAP_-flags to the mmap call (MAP_VARIABLE
is #defined to 0). It is a request to mmap the file at the address
given as base if possible and to mmap it elsewhere if not. Valgrind
intercepts this call and should perform exactly this task: If mapping
at this address isn't possible because it is occupied by a
valgrind-owned mapping, treat this as so-called 'floating mmap', ie
map in some possible location.

The way valgrind seems to treats this is that it always tries to do a
fixed mapping (code is in coregrind/m_syswrap/syswrap-generic and
coreground/m_aspacemgr/aspacemgr-linux) it just selects and address it
'knows' to be good. Quote from am_get_advisory (comments added)

switch (req->rkind) {
case MFixed: /* MAP_FIXED */
if (fixedIdx >= 0) {
*ok = True;
return req->start;
} else {
*ok = False;
return 0;
}
break;
case MHint: /* address w/o MAP_FIXED */
if (fixedIdx >= 0) {
*ok = True;
return req->start;
}
if (floatIdx >= 0) {
*ok = True;
return nsegments[floatIdx].start;
}
*ok = False;
return 0;
case MAny: /* no address in original call */
if (floatIdx >= 0) {
*ok = True;
return nsegments[floatIdx].start;
}
*ok = False;
return 0;
default:
break;
}
From: Moi on
On Thu, 10 Sep 2009 20:55:07 +0200, Rainer Weikusat wrote:

> Moi <root(a)invalid.address.org> writes:
>> On Thu, 10 Sep 2009 05:24:47 -0700, David Schwartz wrote:
>>> On Sep 9, 8:47 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>>>
>>>> But all of this is actually completely besides the point, because the
>>>> library doesn't use MAP_FIXED. According to the comments in
>>>>
>>>>         valgrind-3.4.1/coregrind/m_aspacemgr/aspacemgr-linux.c
>>>>
>>>> this is supposed to work such that either the 'hinted' mapping is
>>>> placed at the intended address (by the kernel) or that valgrind picks
>>>> a suitable replacement address. The file linked-to by the OP doesn't
>>>> contain MAP_FIXED, either.
>>>
>>> I think you're drawing a distinction between the library and the
>>> program that I'm not. In any event, I'm a bit confused now. The OP
>>> specifically stated that an mmap call with MAP_FIXED was failing, and
>>> that it was used in a case where it is not guaranteed to succeed. If
>>> the library doesn't call mmap with MAP_FIXED and the program doesn't,
>>> why is mmap getting called with MAP_FIXED? If valgrind is doing it, it
>>> would be interesting to know the circumstances -- you may be right, it
>>> maybe be a bug in valgrind.
>>
>> relevant part of post++
void* p = mmap(base,
>> mapped_size, PROT_READ|PROT_WRITE,
>> MAP_VARIABLE|MAP_SHARED|MAP_FILE, fd, 0);
>> if (p == (char*)MAP_FAILED) {

>
> This isn't a mapping to a fixed address, for the simple reason that
> MAP_FIXED is not among the MAP_-flags to the mmap call (MAP_VARIABLE is
> #defined to 0). It is a request to mmap the file at the address given as
> base if possible and to mmap it elsewhere if not. Valgrind intercepts
> this call and should perform exactly this task: If mapping at this
> address isn't possible because it is occupied by a valgrind-owned
> mapping, treat this as so-called 'floating mmap', ie map in some
> possible location.

My bad.
I had not even checked the flags, seeing that arg1 was non null.
I stand corrected.

AvK
From: David Schwartz on
On Sep 10, 11:55 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:

> The way valgrind seems to treats this is that it always tries to do a
> fixed mapping (code is in coregrind/m_syswrap/syswrap-generic and
> coreground/m_aspacemgr/aspacemgr-linux) it just selects and address it
> 'knows' to be good. Quote from am_get_advisory (comments added)

Nice detective work. So we might have a workaround for the OP -- if
the mmap fails, try it again without specifying an address.

DS