[MPlayer-dev-eng] [PATCH] (loader/ext.c) VirtualAlloc() SIGSEGV on Linux + other fixes
a.guru at sympatico.ca
Mon Aug 16 23:30:48 CEST 2004
* 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
> Or are these two separate issues?
Issue 2 and 3 are different and deserve individual attention.
The first issue is the same, but the solution is more portable (does
not depend on a specific file in /proc, or the very presence of /proc),
will work in a long-running (g)mplayer process (does not depend on
an initial snapshot of the process' memory maps, which may evolve),
and is less intrusive (if the lines dealing with issue 2 and 3 and the
printf()s are ignored).
I have checked and mmap() with MAP_FIXED will have problems with POSIX systems in
general, not just Linux. See
and in particular the whole paragraph that starts with "If an application
requests a mapping that would overlay existing mappings...", in particular
"new mappings replace any existing mappings".
Nevertheless, if this other patch using /proc were retained, it should
use /proc/self/maps instead of computing a string with the pid in it.
However, Solaris /proc has the /proc/self/map and /proc/self/rmap files
and I don't think they are text, but binary.
More information about the MPlayer-dev-eng