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

[Martin Simmons]

>>>>> On Mon, 16 Aug 2004 17:30:48 -0400, "A. Guru" <a.guru at sympatico.ca> said:

  A> * On Monday 2004-08-16 at 15:07:02 +0300, Jan Knutar wrote:
  >> On Monday 16 August 2004 12:22, A. Guru wrote:
  >> > Changes:
  >> > 
  >> >     * mplayer received a SIGSEGV under Linux after
  >> > 
  >> > 	Opening video decoder: [dmo] DMO video codecs
  >> > 	VirtualAlloc(0x00400000, 859648, 0x00003000, 0x00000040)
  >> > 
  >> >       with
  >> > 
  >> > 	-rw-r--r--  1 root root 807032 Nov 20  2002 /usr/local/lib/codecs/wmv9dmod.dll
  >> > 
  >> >       because that region was already under use and mmap() with MAP_FIXED has
  >> >       problems under Linux (see code).  VirtualAlloc() fixed in "loader/ext.c".
  >> > 
  >> >     * VirtualAlloc() made to conform with win32 documented behavior regarding
  >> >       the alignment of the address and size arguments.
  >> > 
  >> >     * VirtualAlloc() detection of overlap with previous regions fixed.
  >> 
  >> Does this do same thing as
  >> http://article.gmane.org/gmane.comp.video.mplayer.devel/18464
  >> 
  >> Or are these two separate issues?

  A> Issue 2 and 3 are different and deserve individual attention.

  A> The first issue is the same, but the solution is more portable (does
  A> not depend on a specific file in /proc, or the very presence of /proc),
  A> will work in a long-running (g)mplayer process (does not depend on
  A> an initial snapshot of the process' memory maps, which may evolve),
  A> and is less intrusive (if the lines dealing with issue 2 and 3 and the
  A> printf()s are ignored).

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.

__Martin