[mythtv] Mythfilldatabase consuming 100% cpu

[Jim Westfall]

Hi

attached patch should fix.  

If the readyread thread is going to be short lived its possible for 
ShutdownReadyReadThread() to set m_readyread_run had set it to true.  This would cause the thread to never exit.

jim

Russell Mora <rd.mora at gmail.com> wrote [06.21.06]:
> I see this too (everytime) - here is the backtrace I get:
> 
> (gdb) bt
> #0  0x00002b3fded0510b in pthread_join () from /lib/tls/libpthread.so.0
> #1  0x00002b3fdcfaf021 in MythSocket::ShutdownReadyReadThread ()
>   from /usr/local/lib/libmyth-0.19.so.0
> #2  0x00002b3fdf297e65 in exit () from /lib/tls/libc.so.6
> #3  0x00002b3fdf28364b in __libc_start_main () from /lib/tls/libc.so.6
> #4  0x000000000040775a in ?? ()
> #5  0x00007ffffface7e8 in ?? ()
> #6  0x000000000000001c in ?? ()
> #7  0x0000000000000001 in ?? ()
> #8  0x00007fffffacebca in ?? ()
> #9  0x0000000000000000 in ?? ()
> (gdb) info threads
>  2 Thread 1082132832 (LWP 8708)  0x00002b3fdf3195b6 in select ()
>   from /lib/tls/libc.so.6
>  1 Thread 47553347951840 (LWP 8670)  0x00002b3fded0510b in pthread_join ()
>   from /lib/tls/libpthread.so.0
> (gdb) thread 2
> [Switching to thread 2 (Thread 1082132832 (LWP 8708))]#0  0x00002b3fdf3195b6
> in select () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0x00002b3fdf3195b6 in select () from /lib/tls/libc.so.6
> #1  0x00002b3fdcfb7ed3 in MythSocket::readyReadThread ()
>   from /usr/local/lib/libmyth-0.19.so.0
> #2  0x00002b3fded0414a in start_thread () from /lib/tls/libpthread.so.0
> #3  0x00002b3fdf31f943 in clone () from /lib/tls/libc.so.6
> #4  0x0000000000000000 in ?? ()
> (gdb)
> 
> Looks like the readReadyThread is not being woken up from its select() call
> despite wakeReadReadyThread() being called.  Unfortunately I am running the
> release version so there is no more info available, however I did notice
> that there is a whole bunch to data setting in the read buffer of one end of
> the pipe....
> 
> myth_master media # lsof | grep mythfill | grep -v REG
> mythfilld 8670   root  cwd       DIR               22,1      4096     116083
> /dvd/transcode/2
> mythfilld 8670   root  rtd       DIR                3,3      4096          2
> /
> mythfilld 8670   root    0u      CHR              136,2                    4
> /dev/pts/2
> mythfilld 8670   root    1u      CHR              136,2                    4
> /dev/pts/2
> mythfilld 8670   root    2u      CHR              136,2                    4
> /dev/pts/2
> mythfilld 8670   root    6r     FIFO                0,5                17532
> pipe
> mythfilld 8670   root    9r     FIFO                0,5                17584
> pipe
> mythfilld 8670   root   10r     FIFO                0,5                17599
> pipe
> mythfilld 8670   root   11r     FIFO                0,5                17608
> pipe
> mythfilld 8670   root   13u     IPv4              17631                  TCP
> myth_master.homenetwork:47507->myth_master.homenetwork:6543 (ESTABLISHED)
> mythfilld 8670   root   15r     FIFO                0,5                17637
> pipe
> mythfilld 8670   root   16w     FIFO                0,5                17637
> pipe
> myth_master media # netstat -an | grep 47507
> tcp        0      0 127.0.0.1:6543          127.0.0.1:47507
> ESTABLISHED
> tcp      111      0 127.0.0.1:47507         127.0.0.1:6543
> ESTABLISHED
> myth_master media #
> 
> 
> Oh, and I should also say that I probably don't have the head version.....
> 
> HTH
> 
> Cheers,
> Russell.
> 
> On 6/21/06, Nick Rosier <nick.rosier at gmail.com> wrote:
> >
> >On 6/21/06, Daniel A Segel <mythtv-dev at archer-segel.com> wrote:
> >> Torbj?rn Jansson wrote:
> >> > I think there is something wierd going on with mythfilldatabase
> >sometimes.
> >> > Mythfilldatabase sometimes decides to use 100% cpu and not exit
> >properly,
> >> > i've seen this only once before a few weeks ago.
> >> >
> >> >
> >> I just wanted to add that this has also been happening to me every time
> >> it ran for the past few weeks (it also happens if I run it manually). I
> >> updated to rev 10237 and thought it had stopped, but it happened again
> >> last night. I don't know how to run gdb, but if I can provide any other
> >> information that would be helpful in correcting this please let me know.
> >
> >I posted about this a week ago. I seems the problem occurs when the
> >backend is connected to reschedule. It also happens when I run
> >mythbackend --resched.
> >
> >N.
> >_______________________________________________
> >mythtv-dev mailing list
> >mythtv-dev at mythtv.org
> >http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >

> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

-------------- next part --------------
Index: libs/libmyth/mythsocket.cpp
=================================--- libs/libmyth/mythsocket.cpp	(revision 10230)
+++ libs/libmyth/mythsocket.cpp	(working copy)
@@ -636,8 +636,8 @@
             int ret              assert(ret > 
-            pthread_create(&m_readyread_thread, NULL, readyReadThread, NULL);
             m_readyread_run +            pthread_create(&m_readyread_thread, NULL, readyReadThread, NULL);
 
             atexit(ShutdownReadyReadThread);
         }
@@ -683,7 +683,6 @@
     int maxfd;
     bool found;
 
-    m_readyread_run      while (m_readyread_run)
     {
         m_readyread_lock.lock();