[MPlayer-dev-eng] divx audio sig11 bug

[Arpi]

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?


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu