[MPlayer-dev-eng] [PATCH] (loader/ext.c) VirtualAlloc() SIGSEGV on Linux + other fixes

[Robert Lunnon]

See below

On Mon, 23 Aug 2004 09:10 pm, A. Guru wrote:
> * On Monday 2004-08-23 at 19:42:17 +1000, Robert Lunnon wrote:
> > On Mon, 23 Aug 2004 02:48 pm, A. Guru wrote:
> > > * On Friday 2004-08-20 at 00:16:40 +0100, Martin Simmons wrote:
> > > > Yes, I agree.  Your solution of removing MAP_FIXED is neater,
> > > > provided the OS can be trusted to return the requested address.  It
> > > > looks like it can on Linux 2.4.x kernels at least.
> > >
> > > Cool.
> > >
> > >
> > >
> > > There is a more efficient long term solution that would be optimal.
> > > All the various projects that need to implement a win32-compatible
> > > VirtualAlloc() on Linux, such as mplayer and wine (and xine?) (and
> > > avifile?), would benefit from lobbying on the Linux kernel mailing list
> > > for this minimal little patch:
> >
> > And how does this solve antthing for Solaris, which by the way wont
> > necessarily return the requested address except with MAP_FIXED
>
> First, that doesn't mean we can't make things better, even optimal,
> for Linux and any other OS that's willing to implement MAP_NOUNMAP.
>
> I'm assuming you mean Solaris for x86, otherwise the question is moot
> as far as MS Windows for x86 DLLs are concerned.
>
> All operating systems won't _necessarily_ return the requested address
> when MAP_FIXED is not set; that is always the case when the address is
> not available, but some other is.  The question is:  (1) will Solaris
> return the requested address when it is available?  Can you shed some
> light on that specific question?
>
> The Solaris manpage for mmap(2) at
>
>   <http://docs.sun.com/db/doc/816-0212/6m6nd4nbn?a=view>,
>
> states that
>
>   "When MAP_FIXED is set and the requested address is the same as
>    previous mapping, the previous address is unmapped and the new mapping
>    is created on top of the old one."
>
> so Solaris has the same problem with MAP_FIXED as any other
> POSIX-compliant OS and the status-quo is not acceptable.
>
> It does state that
>
>   "A non-zero value of addr is taken to be a suggestion of a process
>    address near which the mapping should be placed."
>
> instead of saying something like "addr is always ignored" so again,
> question 1.
>

The fact of the matter is that this hint IS always ignored under Solaris x86 
(well < 10 anyway). Not only that the memory will ordinarily be allocated 
above d0000000 whereas windows expects everything to be below the 3GB mark, 
normally this doesn't hurt but Alexandre does tell me some windows processes 
are sensitive to this behaviour. He was however not specific about which 
ones.


>
> The other pertinent question is:  (2) is there any MS Windows DLL used
> by mplayer that can't be relocated?
>
Dunno about that, can't say I know a lot about Windows, the caveats are the 
same Solaris kernel/user split is different to Linux and Windows so it will 
locate maps above where the dlls will expect to be located unless you call 
MMAP_FIXED


> If yes to question 2 and no to question 1, then someone will have to write
> an initVirtualAlloc()-type solution that understands Solaris specific
> /proc filesystem binary files /proc/self/map and /proc/self/rmap (or just
> those DLLs won't work).  Is this the case?  If it is, then by all means
> please write such a solution for Solaris with the proper #ifdefs.  Such a
> solution does have a performance penalty and problems with long-running
> gmplayer processes.  A solution that checks /proc every single time will
> have an even bigger performance penalty, but no problem with long-running
> gmplayer processes.
>
> If yes to both questions, then there is no obvious solution anyway.
> That's true for all OSes.  There are _very_ non-obvious solutions for
> several OSes (want to play tricks with the dynamic loader?).
>

There is a solution for Solaris already implemented in Wine which involves 
checking the use of the memory space before mapping to emulate the linux 
behaviour. I assume this is what you are referring to ?


> If no to question 2 and yes to question 1, then Solaris will incur nothing
> else than the same performance penalty that any OS that doesn't implement
> something like MAP_NOUNMAP.
>
> If no to both questions, then Solaris will just incur a performance
> penalty a little more often.  Whether this is better or worse than an
> initVirtualAlloc()-type solution, which can still be written for this
> case, remains to be benchmarked once this is done.

I can't say, I only commented to say that such a change might not be as 
innocuous as you think, because mmap semantics do differ between OSes. I have 
looked at this aspect of wine in the past and tested the original patch.

Assuming the semantics of the dlls are understood (IE what memory they will 
want to map) isn't it then possible to preallocate the space so that 
performance hits occur when we want them to in problematic cases - those that 
fail case 2 and need to call VirtualAlloc frequently .