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

[A. Guru]

* 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 other pertinent question is:  (2) is there any MS Windows DLL used
by mplayer that can't be relocated?

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?).

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.