[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mmap broken - glibc or kernel to blame?



On Sun, Dec 05, 2004 at 05:28:19PM -0500, Jurij Smakov wrote:
> 00010000-00012000 r-xp 00000000 08:11 458670 a.out
> 00020000-00024000 rwxp 00000000 08:11 458670 a.out
> 00024000-08002000 rwxp 00024000 00:00 0 

> mmap(0x10000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 
> 0x10000
> mmap(0x20000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 
> 3, 0) = 0x20000
> mmap(0x24000, 134077000, PROT_READ|PROT_WRITE|PROT_EXEC, 
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x24000

The kernel is fine - you're allowed to do this with MAP_FIXED.  You get
to keep both pieces.

> So, a million dollar question is: whose fault is it? I see two
> possibilities: either ld-linux.so.2 is supposed to make sure that
> there is enough memory available for the mmapping but fails to do it
> for some reason; or this check is supposed to be performed by kernel
> and the mmap call above should not succeed. One point of view,

ld-linux ought to check.  In this particular case, it doesn't.  But if
it did check, the only thing it could do would be to print an error
message and quit.  The executable _must_ be mapped at the linked
address (since it isn't position independent).  ld can't move itself.
The kernel picked where to load ld; it would be nice if it picked
somewhere more useful than 0x08000000 on your architecture.  On i386,
it picks:

80000000-80016000 r-xp 00000000 09:00 11993980   /lib/ld-2.3.2.so
80016000-80017000 rw-p 00015000 09:00 11993980   /lib/ld-2.3.2.so
80017000-8006e000 rw-p 80017000 00:00 0 
 
which gives you up to 2GB for the executable.


-- 
Daniel Jacobowitz



Reply to: