[mythtv] select: Bad file descriptor

Duane Ellis duane at franklin.com
Fri Jan 9 00:12:30 EST 2004


Hello,

I'm trying to write some perl scripts to talk to the myth back end and
I found a way to screw up mythbackend really bad.

The little perl script [below, killer.pl] - causes MYTHBACKEND to
endlessly spew forth: select: "Bad file descriptor" until the hard
disk fills with a multi-gigabyte log file. I have a big disk, I
stopped it before the file got too big

I also get a number of "Unknown socket" messages right before
typically 2 of them one each from the end connection code, and in the
process request code part of mainserver.cpp.

To kill mythbackend - do this:

Start mythbackend like this;

      ./mythbackend -d

Run my perl script [below] like this;

      perl ./killer.pl

This has been reported before by others - with no resolution:
     http://mythtv.org/pipermail/mythtv-users/2003-April/001944.html

And at TrollTech - 
     http://lists.trolltech.com/qt-interest/2003-08/msg00591.html

I can't find anything else in the mail list archives.

The *closest* thing I can find in QT source code that fits the pattern
is this message is: (can't find any other place)

   /usr/src/qt-x11-free-3.3.0b1/src/kernel/qeventloop_x11.cpp
   line: 384

However - the commentary & code flow there implies otherwise.

BUT - what I see when I use strace to help track the problem down it
looks like it is trying to close down the problem socket and is doing
exactly that code. Perhaps the threading is screwing me up...

----------------------------------------

I've also tried debugging with GDB.... Sadly - I can't set a break
point in a shared library with (a) no symbols and (b) on an arbitary
call to a system function with parameters set a ceritan way.

I did try to get the QT-3.1 source and rebuild it so I could prove it
but cannot get there. Not so simple when you concider all of the
./configure options it needs (ie: RH9 needs which ones?) And no -
using the srpm is not any good - I have too many conflicts between
package X vrs Y vrs Z ... etc/

I'm very certian that the problem is occuring in a shared libary the
PC at the time of the failure [gleened from strace with the -i option
that prints the PC at time of call] shows that it is in the shared
address space {some where around 0x40xxxxxx] where as the application
is all in the 0x08xxxxxx area. I can't figure out which module though.

----------------------------------------

My perl script is here.

>> -- CUT HERE --
>> #!/usr/bin/perl -w
>> use strict;
>> use IO::Socket;
>> use IO::File;
>> 
>> my $host   = "localhost";
>> my $port   = 6543;
>> my $r;
>> 
>> my $str;
>> my $s;
>> $str = "ANN Playback borgcube 0";
>> $s = sprintf("%-8d%s", length($str), $str );
>> $r = IO::Socket::INET->new( Proto => "tcp",
>> 			    PeerAddr => $host,
>> 			    PeerPort => $port );
>> $r->send($s);
>> close($r);
>> -- CUT HERE --

Yes - perhaps I'm doing something wrong/nasty with the perl script, in
this case I am. However - backend is a server as such it must/should
deal with the fact that clients *DIE* at the *WRONG* timem, and
connections go down at the *WRONG* time and it should recover from it.

In my case, I had some typos in another file that I was working with
that caused my perl application to puke.
 
On a simular subject - Besides using ethereal to packet sniff and
reading the source code for both frontend & backend - is there any
other place to get the protocol documentation?

--Duane.


More information about the mythtv-dev mailing list