On Sun, Apr 27, 2008 at 09:01:55PM -0400, Albert Lee wrote: > Hi, > > I'm trying to fix a problem in Wine that is caused by a shared library > mapping by the dynamic linker. Wine's memory management facility keeps > track of where some libraries are mapped and assumes they occupy a > contiguous range of the process address space. > > However, in some cases they are not contiguous. In the following > example, there is a 56K "hole" (containing a single page?) between > sections of a library at 7FFB0000. > > 7FF20000 448K r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so > 7FF90000 4K rw--- /export/ws/wine/dlls/ntdll/ntdll.dll.so > 7FF91000 120K r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so > 7FFB0000 4K rw--- > 7FFBE000 40K rwx-- /export/ws/wine/dlls/ntdll/ntdll.dll.so > 7FFC8000 72K rwx-- /export/ws/wine/dlls/ntdll/ntdll.dll.so
Just to make this a tad more explicit: start end perms notes 7ff20000 7ff90000 r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so 7ff90000 7ff91000 rw--- /export/ws/wine/dlls/ntdll/ntdll.dll.so 7ff91000 7ffaf000 r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so 7ffaf000 7ffb0000 ----- 1k hole 7ffb0000 7ffb1000 rw--- (new anonymous memory) 7ffb1000 7ffbe000 ----- 13k hole 7ffbe000 7ffc8000 r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so 7ffc8000 7ffda000 r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so > The problem is that an mmap after the library is loaded can occupy that > "hole", which then appears as an overlapping segment to Wine's memory > management (http://bugs.winehq.org/attachment.cgi?id=12470 ). So there's a 15k "hole", which the OS sees as perfectly valid space to shove a new MAP_ANON segment. Does that match what you're thinking? Cheers, - jonathan > What is responsible for this "hole"? Is there a way to prevent it when > creating the object file for the library? > > Thanks! > > -Albert > > > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org
