Infinite loop in mythbackend

[ian@…]

With mythbackend from 0.20+fixes svn branch, I see the backend going into a state where it is using 100% of CPU. I compiled with profiling and used oprofile, which shows

Profiling through timer interrupt samples % linenr info image name app name symbol name 15006 96.2725 videooutbase.cpp:513 libmythtv-0.20.so.0.20.0 mythbackend VideoOutput::GetVisibleOSDBounds(float&, float&) const

This is with the backend doing nothing apparent at all. ie, not watching live tv, not recording, not commercial flagging. This is weird, because I don't know why the backend would be spending time in GetVisibleOSDBounds at all.

If I stop and restart the backend, it settles back to normal, then something unidentified triggers it to go into this tight loop.

[ian@…]

I tried to add an opannotate listing as an attached file, but got an Internal Error:

Akismet rejected spam

[halovanic@…]

I can confirm the exact same problem here. I've recompiled from source several different times and tried the binary packages, but all have the same problem, and I can't find anything in the logs about it. I was wondering if there was something peculiar in my hardware or database that was causing this since nobody else had noticed it.

[anonymous]

Backtrace (but not very helpful it seems)

[JonasPed <jonas@…>]

Can confirm same thing on gentoo with ebuild mythtv-0.20_p11244. Would be really nice to have fixed in 0.20 fixes.

[cpinkham]

Please try the attached patch and see if it fixes the issues.

[ian@…]

It seems to work great so far, though I haven't tested it much, my mythbackend is loafing along at 2-3% again.

[halovanic@…]

The patch hasn't fixed the problem for me, CPU usage is still hitting 50% for mythbackend after running overnight.

[cpinkham]

If this is still happening for you, please submit a backtrace of mythbackend from when the problem is occurring. Follow the instructions in the HOWTO for information on how to get a backtrace when the program isn't actually crashing.

[cpinkham]

(In [11299]) Carries over [11298] from trunk.

Don't try to reinit the OSD if we're using_null_videoout in NVP (ie, transcoding or commercial flagging or building the preview pixmap).

References #2438.

[ijr]

Original issue should be fixed. Please reopen with backtrace and/or profiling info if not.

[halovanic@…]

Sorry, I think I failed to clean out the old version properly the first time. After reinstalling, mythbackend has taken everything I can throw at it.

[thetaz]

I am still seeing high cpu load on my mythbackend running the latest .20-fixes branch from tuesday. The only way to get rid of the high cpu load is to reboot the backend process. I have been unable to determine when this begins but it almost seems to be random now after the above fix had been applied. I have compiled profiling in, however I am unfamiliar wtih oprofile and I need to know which oprofile commands will produce the most relevant results as to why the back end is looping.

From what I can tell so far, my backend is entering some of the QT header files. I do not run X server on that system and do not have a display attached, should that be happening? It is strictly mythbackend only.

[thetaz]

I don't know how applicable this is, but here is the backtrace from the running mythbackend process while it is using high cpu load: (gdb) backtrace #0 0xffffe410 in kernel_vsyscall () #1 0xb5e830c1 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb642aa8d in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #3 0xb649e947 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #4 0xb649e86a in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #5 0xb6484965 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #6 0x08084a07 in main (argc=6, argv=0xfffffdfe) at main.cpp:682

[thetaz]

Any updates to this? I will be more than happy to supply any additional information. I have recompiled a couple times with the latest SVN revision's and nothing has improved. The backend still goes into a 100% cpu usage cycle randomly.

[cpinkham]

I replied to the comment in email, but I guess you don't read -dev. Do you use the new UPNP feature or do you have any UPNP devices on your network? Both backtraces in this ticket show UPNP code being executed at the time so I'm wondering if this is related.

[thetaz]

Sorry, I don't read -dev at all, but yes..

I have a linksys WRT54G router with custom firmware that has uPnp turned on. This is the only device that has it turned on when this is happening. It seems like this is happening when I do not have any other computers or devices turned on that are connected to my WRT54G switch. Ie, I will have mythbackend at 0% cpu usage when going to sleep, shut down all devices/systems then wake up in the morning at mythbackend is cycling at 99.9% cpu. Mythbackend will still allow me to connect so it seems like it is a thread. Therefore, it may be possible that the router is sending a packet out to the network that is triggering the uPnp on my backend. The branch I'm using is .20-fixes but I see that the other branch has a --noupnp option so I will compile that and run it with that option to see if my results improve.

I also ran opannotate after I had left oprofile running for a couple of days and allowed the backend to loop for over a day at 100% cpu, I will attach a copy of the summary output to this ticket but it looks like it is in fact using a lot of cycles in the uPnp feature.

Thanks

[thetaz]

Very high uPnp usage shown in opannotate summary

[adeffs.mythtv@…]

my backend trace

[thetaz]

Update: I've ran the backend for 2 days now using Thursday afternoon's SVN of the unstable .20 branch with the --noupnp flag and have not had any further issues with the backend going into a 100% cpu loop. I'm seeing consistently average 0% cpu usage by the backend, just as was the case before I upgraded into the .20 release of MythTV.

I am willing to work with development to fix the loop in the uPnP code if a possible fix has not already been researched.

Thanks

[cpinkham]

(In [11533]) Carries over [11461] from trunk.

Under a loose definition of the word "fix", I'm applying the --noupnp patch to -fixes since it allows people with the "mythbackend is consuming 100% cpu" issue to actually use mythbackend right now. The real fix is inside the upnp code somewhere, but this is a stop-gap measure for now.

References #2438.

[cpinkham]

I believe this was fixed a while back and the ticket was left open.

[anonymous]

sadly, it's not fixed using the latest svn... :(