[MPlayer-dev-eng] divx audio sig11 bug

[Fredrik Kuivinen]

On Tue, Apr 23, 2002 at 03:36:48AM +0200, Arpi wrote:
> Hi,
> 
> I've spent this night by debugging and tracing the misterious divx audio
> sig11... thanks to JALH for the shell acc.
> 
> about the bug: a few users (~ 5 reported) have this problem. common: they use
> gcc 2.95.x (but afair same with 3.x) and glibc 2.1.x (x==3 ??).
> afair the bug has gone when one of them upgraded glibc to 2.2
> 
> 
> what have i found?
> 
> the bug is not triggered by -fomit-frame-pointer, as Nick said earlier.
> it's triggered by the LARGEFILE support!!!
> 
> sig11:
> CFLAGS=-I. -I.. -O -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 $(EXTRA_INC) $(WARN_FLAGS)
> 
> works:
> CFLAGS=-I. -I.. -O -D_LARGEFILE_SOURCE $(EXTRA_INC) $(WARN_FLAGS)
> 
> i've traced the bug down to a single function, in ext.c:
> 
> LPVOID FILE_dommap( int unix_handle, LPVOID start,
>                     DWORD size_high, DWORD size_low,
>                     DWORD offset_high, DWORD offset_low,
>                     int prot, int flags )
> 
> i can compile everything but this with _FILE_OFFSET_BITS=64 to get it work.
> if i compile this func with _FILE_OFFSET_BITS=64, it's sig11 very early.
> 
> this func extensively uses mmap and munmap, these are mapped to mmap64/munmap64
> if _FILE_OFFSET_BITS=64 is defined.
> 
> the code causing the sig11 reads pointer from fixed memory address.
> probably the mmap/munmap fail somehow and gives bad address etc. so the data
> segment will be loaded at wrong place so causing sig11.
> 
> diff of outputs of working and sig11 code:
>  ***FILE_dommap(-1,0x1c201000,0,122368,0,0,3,12) -> 0x1c201000
>  ***FILE_dommap(8,0x1c201000,0,122368,0,600,7,12) -> 0x1c201000
>  /usr/lib/win32/divxa32.acm: mmaping section .data at 0x1c21f000 off 1e400
> size
> +***FILE_dommap(-1,0x1c21f000,0,35840,0,0,3,12) -> 0x1c21f000
>  ***FILE_dommap(8,0x1c21f000,0,35840,0,1E400,7,12) -> 0x1c21f000
>  clearing 0x1c227c00 - 0x1c228000
>  /usr/lib/win32/divxa32.acm: mmaping section .data1 at 0x1c22e000 off 27000 size
> 
> so the working version calls one more FILE_dommap(). strange.
> 
> i don't understand the win32 loader, so i'm unable to continue this, it goes
> too deep inside the internals :(((
> 
> does anyone have any idea? al3x? jalh?
>

I found this comment in memory/virtual.c in the wine cvs tree:

/*
*           unaligned_mmap
*
* Linux kernels before 2.4.x can support non page-aligned offsets,
* as
* long as the offset is aligned to the filesystem block size. This
* is
* a big performance gain so we want to take advantage of it.
*
* However, when we use 64-bit file support this doesn't work because
* glibc rejects unaligned offsets. Also glibc 2.1.3 mmap64 is broken
* in that it rounds unaligned offsets down to a page boundary. For
* these reasons we do a direct system call here.
*/

The last paragraph is the interesting one. 

IMHO FILE_dommap is a real mess in the mplayer tree. Copying the
relevant code from memory/virtual.c would probably make this bug go
away and it will make the code a whole lot easier to read.

/ Fredrik