Memory Leaks -> Lockup?

[stevech]

WAF problem.
Morning in the house: flip on TV/Sage. Uh Oh. Screen shows Sage's Logo with the spinning triple circles (the A in SAGE) - the please wait indicator.

This is a stock current release 4 system. No fancy stuff - no DVD, music, HD. Just DVR of Std Def TV. One tuner. Stock GUI.
Hasn't been rebooted for weeks.

I grab a screen showing process status (enclosed). Says memory and VM is up to almost 256MB.
1,900 handles (window elements) in use.

Cannot get Sage to terminate.
Windows shutdown hangs (maybe becuase sage won't exit).
Cross-fingers, force power off.
Rebooted fine. no apparent damage.

Grab another process status of Sage, 12 hours and may viewings later.
Memory is 99MB.

Memory leaks?

enclosed: screen grabs

[gplasky]

Current release is v5.0.2.

Gerry

[blade]

Narflex has posted before that what windows reports for Sage memory usage is incorrect and that the fluctuations in memory is due to java doing its thing. I don't know enough about it to explain it, but you can do a forum search for the thread Narflex replied in or maybe someone else can better explain it.

[BBCritical]

I have had the same issue with v5.0.2 and when I look in the debugging log I get java out of memory errors...

[bcjenkins]

I can add that when I hit 225,000 in memory for SageTV.exe. It breaks. I run in service mode so it is not as big of a deal because recordings continue. It is just painful because I can't relaunch SageTV.exe from my MCE remote without HIP or Girder (which are not installed) It takes me about 2-3 days for SageTV to get to the breaking point. I'll turn on logging to file a bug report.

B

[Narflex]

If you're getting OutOfMemory errors in your log file, PLEASE submit a bug report. Those should not be happening. http://sagetv.com/bugs.html

[stevech]

apologies in advance for dumb user response...

What about Windows reporting 1900 handles in use? Doesn't this imply a problem?

Out Of Memory Errors? These would be in the file tv.sage.mod.0.log?
Well - that file seems to be erased each time you startup Sage.
So when Sage locked up and wouldn't terminate, I don't know why - there were no errors presented via the OSD and I cannot access the log file. Sage stopped responding to the window manager so I can do nothing. Could not shut down Windows.

After restarting Sage, the log file above contained just the most recent startup events. There were a number of WARNING symbolMap Duplicat Theme: xxx
----------
Perhaps there's a different logfile I'm supposed to look at for post-morteum.

[Opus4]

See this FAQ entry for info on debug logging.

- Andy

[nielm]

Note that Windows taks manager memory usage (and also that reported by my Motherboard Information plugin) includes memory that is allocated by other things -- some that sage has no control over:

• Sage's native (non-java) code layer
• Native (non-java) code from thrd-party plug-ins
• DirectShow DLLs for the capture cards
• DirectShow DLLs for playback -- decoders, post-processors, renderers etc

A bug / memory leak in the latter 3 would be unfixable by Sage, and it would be very difficult to trace the source.

I recent traced down a massive memory leak to my use of FFDSHOW's kernel deinterlacing filter -- each time I Skipped in Sage, a few 100K was leaked... (this was easy to see when I used my motherboard info plugin, graphing the memory use for Sage)...

Try falling back to the basic configuration: no plugins, no custom STVs, use Sage's decoders, no post-processors, and see if you still have your memory leak, if not, add each customization in turn until you find the culprit.

[stevech]

As I said - I have a vanilla system already. No 3rd party decoders or plug-ins. Hauppauge hardware.
It's a blame game?

What about the 1900 handles?

[bcjenkins]

My SageTV.exe says 393,859 handles and 28 threads.
Is that alot?

B

[nielm]

Note that 'Handles' are anything that is system-wide that sage needs to have access to, not just window elements (eg file handles, thread handles, registry keys, device handles...)

On my system, using service mode and with assorted customisations I have:
On startup:
SageTV: 121MB VMsize, 750 handles
SageTVService 65Mb, 1028 handles

While playing back something (after 20 secs)
SageTV: 135MB VMsize, 2697 handles (increasing)
SageTVService 68Mb, 1028 handles

After stopping playing back something
SageTV: 125MB VMsize, 2597 handles
SageTVService 68Mb, 1028 handles

After a few days:
SageTV: 175Mb (stable), 350,000 handles
SageTVService: 76Mb, 1140 handles

hmm so there does seem to be some kind of 'handle leak' on my system (some more playing with decoder/renderer reveals that it is only when I use VMR9 as my renderer, and it creates about 50 new handles/sec)

[Azam]

After just one night of having the sagetv client running on my computer (probably watched around 3-4 hours of shows) my client computer showed 1,024,000 handles. (Running 5.02) It only showed about 18mb memory usage though.

[Narflex]

Originally Posted by nielm

Note that 'Handles' are anything that is system-wide that sage needs to have access to, not just window elements (eg file handles, thread handles, registry keys, device handles...)

On my system, using service mode and with assorted customisations I have:
On startup:
SageTV: 121MB VMsize, 750 handles
SageTVService 65Mb, 1028 handles

While playing back something (after 20 secs)
SageTV: 135MB VMsize, 2697 handles (increasing)
SageTVService 68Mb, 1028 handles

After stopping playing back something
SageTV: 125MB VMsize, 2597 handles
SageTVService 68Mb, 1028 handles

After a few days:
SageTV: 175Mb (stable), 350,000 handles
SageTVService: 76Mb, 1140 handles

hmm so there does seem to be some kind of 'handle leak' on my system (some more playing with decoder/renderer reveals that it is only when I use VMR9 as my renderer, and it creates about 50 new handles/sec)

Can you submit a bug report on this please?

[mike1961]

Yes - there appears to be a handle leak somewhere. I had over 600,000 handles (forgot to mention - that was with Sage restarted today). Didn't even know it until I read this thread. Here's the intersting thing, if I turn off VMR9 and set it to overlay, the leak stops. I can do this while keeping the task manager open and monitor it. The moment I watch a video and I have details set to VMR 9 it starts incrementing the handles. If I set it to overlay, it stops. I tried both Sage and NVidia decoders and it didn't seem to matter - but overlay stops it and VMR9 starts the leak (finally got those nvidia decoders working but I'm not noticing any quality difference - maybe I need glasses or something).

FWIW - I set my debug logging to TRUE in properties and I have the Sage log. If someone is interested, let me know where to send it.

Thanks,
Mike

[mike1961]

Well - the VMR9 setting only seems to create the handle leak on my computer in one room and not the other two. There are some differences like it's happening on my Intel 2.66 ghz computer and not on the AMD 3200's. Could be something else causing it of course but I can make it happen on one computer by using the VMR 9 setting.

EDITED - Scratch that. I have to check the other computers again because I did not change the channel after changing the setting...just a sec on this.


Mike.

[mike1961]

Yes - it does it on all the computers. I set to VMR9 and then watch TV (but not a show already watched if you change settings) just change the channel bring up the task manager and watch you handles just start increasing by the second.

Mike

[jominor]

Originally Posted by nielm

Note that 'Handles' are anything that is system-wide that sage needs to have access to, not just window elements (eg file handles, thread handles, registry keys, device handles...)
)

I have Sage, running as an exe and running for at least 3 months with 1115. Note, this is with 2.x. I have yet to upgrade, so this leak appears new.

[stevech]

VMR9 off on mine with the handle leak problem in version 4

[mike1961]

I have version 5 and it only happens with VMR9. But I also have the latest Java version which could be part of the problem.

Not at all sure how long it has been going on.

Mike.