Re: [Valgrind-developers] mmap strangeness on ppc32-linux

[Tom H. <to...@co...>]

In message <178...@ca...>
        Paul Mackerras <pa...@sa...> wrote:

> Julian Seward writes:
>
>> V starts up OK and loads /bin/bash and its ELF interpreter as usual, and
>> starts it.  However, at some point ld.so is doing some fixed mmaps for the 
>> 3 .so's mentioned above, and these are failing:
>> 
>> sys_mmap ( 0xFFFDE000, 69636, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC)
>> sys_mmap ( 0xFFFD9000, 90236, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC)
>> sys_mmap ( 0xFFFA1000, 319664, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC)
>> 
>> This strikes me as strange because the addresses (0xFFFDE000 etc) are almost
>> at the end of 4G.  It's also strange because other programs, including large
>> ones, run just fine, and these .so's are mapped quite low, as is normal.
>
> It looks like those libraries have been prelinked on a 64-bit system
> and then moved to a 32-bit system.  32-bit processes get more address
> space (4GB) on a 64-bit machine than an a 32-bit machine (where they
> get either 2GB or 3GB).
>
> However, I would expect the dynamic linker to recover from the mmap
> failure and just retry by mapping the library somewhere else.
> Strange.

That's not how prelinking handles failures. If you look at those mmap
calls you will see that although there is an address given, the flags
do not include MAP_FIXED so the address is only a hint.

What mmap is supposed to do is that if it can't use the supplied
address then it should just choose another one at random. The dynamic
linker will then notice that the mapping didn't happen at the
prelinked address and do the relocations to fix things up.

The fact that valgrind is returning ENOMEM will make the dynamic
linker think that there really isn't enough memory anywhere in the
process space to map the library, so it will give up.

Tom

-- 
Tom Hughes (to...@co...)
http://www.compton.nu/