Re: Bug in mmap()

[Michael Vergoz <mv at binarysec dot com>]

Hello

Excuse me to tell you that but MAP_ANON and MAP_SHARED aren't  
compatible.

Map anonymous memory isn't associated with any specific file. The  
file descriptor used for creating MAP_ANON regions is used only for  
naming, and may be specified as -1 if no name is associated with the  
region.

MAP_SHARED mean that modifications are shared in the file and it  
*need* this file. And every modification from your memory map will be  
updated as soon as possible or you can force the action with msync().

In normal case, in normal world :) you shouldn't MAP_ANON with  
MAP_SHARED. The MAP_SHARED management is really difficult and really  
different MAP_PRIVATE.

You may read the manual for more futher.

This message is also valid for the BUG #2007 reported by Bruce Korb.

Michael Vergoz

Le 8 déc. 05 à 21:59, Bruce Korb a écrit :

> Hi all,
>
> An issue in my code reveals a bug in mmap():
> /lib/libc.so.6.1 Linux/alpha 2.6.13.2
>
> > My mapping descriptor structure shows this:
> >
> > (gdb) print *pMI
> > $2 = {txt_data = 0x2000001c000, txt_size = 8192, txt_full_size =  
> > 16384,
> >  txt_fd = 7, txt_zero_fd = -1, txt_errno = 0, txt_prot = 0,  
> > txt_flags = 0,
> >  txt_alloc = 0}
> >
> > Immediately before this call:
> >
> >        pNuls = mmap(
> >                (void*)(((char*)pMI->txt_data) + pMI->txt_size),
> >                pgsz,
> >                PROT_READ|PROT_WRITE,
> >                MAP_ANONYMOUS|MAP_FIXED|MAP_SHARED, 0, 0 );
> >
> > The address passed is:
> >
> > (gdb) print 0x2000001c000+8192
> > $5 = 0x2000001e000
> >
> > It seg faults instead of returning ((void*)-1).
> So, the "|MAP_SHARED" dinkleberry is left over from the copied text
> where I am mapping a real file.  Anyway, his call should either work
> or return ((void*)-1).  Not seg fault.  Handling a seg fault is
> painful.  This could be a kernel issue, of course, but libc is
> between my code and there, so I am reporting it to you....Thanks -  
> Bruce