Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: David Asher <david.asher <at> caviumnetworks.com>
Subject: Bug when running transcode from httpd
Newsgroups: gmane.comp.video.transcode.devel
Date: Thursday 16th February 2006 03:59:45 UTC (over 10 years ago)
Ok, this is a little involved, so hang with me.  I'm pretty sure I've 
found a problem in 1.0.2 and current CVS HEAD.

The root of the problem is the file descriptor abstraction in libxio, 
mixed with the usage of fdopen.

In tcprobe.c, when probe_path returns TC_PROBE_PATH_FILE, xio_open() is 
called to open the input file.  In this case, this is the first file to 
be opened by tcprobe so 3 is used for the abstracted descriptor (ret_fd) 
inside libxio.c xio_open().  When the unix io fallback is used, 
_handles[3]->data is set to the file descriptor open() returns.  This 
works fine IF AND ONLY IF open returns the same value as ret_fd (3 in 
this case) -- see below.

In my case, when transcode is run from a script spawned by httpd, open() 
returns 15.  So the file is open on file descriptor 15 and xio_open 
returns 3 to ipipe.fd_in @ tcprobe.c:251

Next &ipipe is passed to tcprobe_thread(), which calls probe_pes().  At 
scan_pes.c:530, ipipe->fd_in is used in a call to fdopen to get a FILE* 
-- but ipipe->fd_in is 3 (the abstracted file descriptor returned by 
xio_open) -- not the REAL file descriptor, that's 15.  The subsequent 
calls to fread all fail, causing all sorts of bad things to happen.

Is my logic wrong?  I'll work on a patch.

David.
 
CD: 4ms