Opened 18 years ago
Closed 17 years ago
Last modified 16 years ago
#2438 closed defect (fixed)
Infinite loop in mythbackend
Reported by: | Owned by: | cpinkham | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | 0.20 |
Severity: | high | Keywords: | CPU load |
Cc: | jonas@… | Ticket locked: | no |
Description
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.
Attachments (5)
Change History (26)
comment:1 Changed 18 years ago by
comment:2 Changed 18 years ago by
Priority: | major → minor |
---|
comment:3 Changed 18 years ago by
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.
Changed 18 years ago by
Attachment: | mythbackend.backtrace added |
---|
Backtrace (but not very helpful it seems)
comment:4 Changed 18 years ago by
Cc: | jonas@… added |
---|
Can confirm same thing on gentoo with ebuild mythtv-0.20_p11244. Would be really nice to have fixed in 0.20 fixes.
Changed 18 years ago by
Attachment: | bug2348.patch added |
---|
comment:6 Changed 18 years ago by
It seems to work great so far, though I haven't tested it much, my mythbackend is loafing along at 2-3% again.
comment:7 Changed 18 years ago by
The patch hasn't fixed the problem for me, CPU usage is still hitting 50% for mythbackend after running overnight.
comment:8 Changed 18 years ago by
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.
comment:9 Changed 18 years ago by
comment:10 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Original issue should be fixed. Please reopen with backtrace and/or profiling info if not.
comment:11 Changed 18 years ago by
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.
comment:12 Changed 18 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:13 Changed 18 years ago by
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
Changed 18 years ago by
Attachment: | mythbackend-10062006.backtrace.txt added |
---|
comment:14 Changed 18 years ago by
Owner: | changed from Isaac Richards to cpinkham |
---|---|
Status: | reopened → new |
comment:15 Changed 18 years ago by
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.
comment:16 Changed 18 years ago by
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.
comment:17 Changed 18 years ago by
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
Changed 18 years ago by
Attachment: | opannotate-10122006.txt added |
---|
Very high uPnp usage shown in opannotate summary
comment:18 Changed 18 years ago by
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
comment:19 Changed 18 years ago by
(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.
comment:20 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I believe this was fixed a while back and the ticket was left open.
I tried to add an opannotate listing as an attached file, but got an Internal Error:
Akismet rejected spam