Hi, I've been tracking down a very odd bug this afternoon. As it turns
out it is caused by enabling xine's mmap() support for the input_file.c.

I'm running 32 bit linux 2.6.21. The file in question is 0x10e4da000
bytes long (you can probably guess what kind of bug this is by now :)

Anyway, the issue stems from the definition of mmap():

void *mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset);

compare this to the definition of st_size in struct stat:
off_t     st_size;    /* total size, in bytes */

On my machine (in input_file.c) sizeof(size_t) ==4, whilst
sizeof(off_t) == 8. However the compiler doesn't generate a warning
when the following is done in xine's code:

     if ( (this->mmap_base = mmap(NULL, sbuf.st_size, PROT_READ,
MAP_SHARED, this->fh, 0)) != (void*)-1

So it silently truncates the upper part of the length. Obviously you
cannot mmap() a file that large into (32 bit) memory anyway, but as it turns
out, mmapping() 0xe4da000 succeeds, which causes... problems.

The patch (against xine-lib 1.1.6) does two things:
* Check that the length will not be truncated, while still allowing
for mmap()s of large files under 64 bit OSes.
* A correctness fix: if mmap() fails, this->mmap_base will be set to
0xffffffff. Later on when the file is closed, this means it was
attempting to do munmap(0xffffffff).

 development branche
Am Samstag, 26. Mai 2007 17:48 schrieb Darren Salt:

> Could you also try not reverting that and instead applying one or
> both of the attached patches? Both playback and eject need to be
> tested. You should use the drive's eject button, though there's no
> harm in also checking xine-lib's eject code.

Ok, here's a modified patch, a combination of your two patches, with a
little fix. It works fine here, pressing the vcd button on xine-ui
starts playing vcd's directly and when pressing the stop button, I can
eject the CD by pressing the eject button on the cd drive.

I hope it's ok for you.

--
Machs gut    | http://www.iivs.de/schwinde/buerger/tremmel/
             | http://packman.links2linux.de/
Manfred      | http://www.knightsoft-net.de

The current input_v4l in xine-lib 1.1.6 is inherently buggy (it will
deference an invalid pointer in extract_mrl if the MRL contains a V4L input
name or frequency).

The attached patch applies after my logging patches (I can regenerate if
needed).

demux_ts attempted to read packets from the input 200 times before
giving up. When playing a local file, this is harmless, as it will hit
EOF 200 times; however, input_dvb waits 5 seconds for packets on each
call to read, resulting in a 1000 second delay if tuning fails.

Remove the counting of input packets, and add a comment to read() in
input_plugin.h, to indicate that we expect inputs to try and return some
data when read() is called. This fixes the delay, and makes it clear to
future maintainers that they shouldn't expect to loop like this.
--
Simon Farnsworth

The three attached patches (against 1.1.6) each increase the amount of
debug logging in their respective components. We've found the extra
logging useful when trying to track down faults.

I've split this into three patches to make it easier to apply only some
of our changes.
--
Comments welcome,

Simon Farnsworth

Patch from Dmitri Fedortchenko <dimo <at> angelhill.net>, required
for upstream Totem bug:
http://bugzilla.gnome.org/show_bug.cgi?id=418316