Opened 8 years ago

Closed 7 years ago

#11352 closed Bug Report - Memory Leak (Works for me)

Leak in MythPainter::DrawTextLayout

Reported by: Bradley Baetz <bbaetz@…> Owned by: jpoet
Priority: minor Milestone: 0.27
Component: MythTV - User Interface Library Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no


I've been noticing increased memory usage with mythfrontend in 0.26 vs 0.25. Its been happening since I upgraded shortly after 0.26 was released. The symptom is a gradual leak (as shown with top/free), but sometimes the memory usage increases by 50-100M over an hour or so.

I haven't been able to work out what the trigger for this difference is, but I've been running my frontend under valgrind for the past couple of weeks to track it down.

The attached log (Using 0.26-fixes-72bca07 plus the patch for #11329, on ubuntu 12.04) is from a run that had an uptime of just under a day. there was one 30 min recording (HDHR) during that time, plus watching a couple of recorded shows and videos. It was cleanly shutdown (exit from the mainmenu) (by this stage watching a recording was stuttering because the box was swapping. This whole setup is a bit fragile perf-wise - valgrind on an HP microserver only works with vdpau...)

the log shows 112M of "possibly lost" allocations. A bit over 80M of that comes from MythPainter::DrawTextLayout?, so I'm assuming that that's where the leak is. However there's also a bit more from other things (eg MythPainter::DrawRoundRect?), so maybe its something else leaking?

Using the Steppes theme, in case that matters

I've also attached a log (valgrind.donothing) of mythfrontend where all I did is wait a few minutes and then shut it down again (as a baseline)

valgrind was run as "valgrind --leak-check=full --show-reachable=yes --undef-value-errors=no --num-callers=50 --log-file=/tmp/valgrind.%p" with the patch from applied.

Attachments (3)

valgrind.leak.log.gz (496.2 KB) - added by Bradley Baetz <bbaetz@…> 8 years ago.
Leaking log
valgrind.donothing.log.gz (168.8 KB) - added by Bradley Baetz <bbaetz@…> 8 years ago.
Baseline logfile
helgrind.patch (708 bytes) - added by jpoet 8 years ago.

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by Bradley Baetz <bbaetz@…>

Attachment: valgrind.leak.log.gz added

Leaking log

Changed 8 years ago by Bradley Baetz <bbaetz@…>

Attachment: valgrind.donothing.log.gz added

Baseline logfile

comment:1 Changed 8 years ago by stuartm

Component: MythTV - GeneralMythTV - User Interface Library
Milestone: unknown0.26.1
Owner: set to jpoet
Status: newassigned

comment:2 Changed 8 years ago by stuartm

Type: Bug Report - GeneralBug Report - Memory Leak

comment:3 Changed 8 years ago by jpoet

I have spent a couple of hours trying to spot a leak in the MythPainter? code, and don't see one. I believe that valgrind is getting confused by the fact that MythImage? objects delete themselves when they are no longer needed.

comment:4 Changed 8 years ago by Bradley Baetz <bbaetz@…>

Maybe, but the increased memory usage shows up in top. If the objects don't delete themselves on a clean exit, that would cause the valgrind false positive, though.

Although something is causing mythfrontend to grow by 500-700MB over a week. I'll run it with valgrind for a bit longer and see if anything else shows up.

comment:5 Changed 8 years ago by jpoet

Hey, I didn't close the ticket as invalid ;-) I am just saying that finding the leak is going to be difficult, since it looks like there may be a lot of red-herrings.

comment:6 Changed 8 years ago by Bradley Baetz <bbaetz@…>

Is it better to do a clean shutdown (from the main menu) or just kill -9 (to avoid any skipping any caches that are cleaned up at shutdown but not before)?

comment:7 Changed 8 years ago by jpoet

valgrind is reporting so many false positives that I am not really sure how useful it is. If you have valgrind-devel install, you can use the attached patch to cut down some of the false positives, but there are still plenty left.

Changed 8 years ago by jpoet

Attachment: helgrind.patch added

comment:8 Changed 8 years ago by Bradley Baetz <bbaetz@…>

That's for helgrind annotations, isn't it? Shouldn't affect the valgrind memory leak detection unless I'm missing something.

comment:9 Changed 8 years ago by paulh


comment:10 Changed 8 years ago by paulh

I wonder if what you are seeing here is the image caches filling up over a period of time?

The software image cached is 96M alone which on my system takes a while to fill up but it does make it look like the FE is leaking when all it's doing is filling the cache.

For example if you have a theme with the time on the main menu then each time the time updates a new image is created which gets added to the cache. If you observe the memory usage it looks like it's leaking but all that is happening is the memory cache is filling up. It will stop when it reaches the maximum size allowed.

You could try lowering the cache sizes in mythpainter.cpp change the values passed to SetMaximumCacheSizes?(96, 96);

comment:11 Changed 8 years ago by bbaetz@…

Possibly that's what the valgrind log is showing, however it was getting to 1-2 gigs over a week or so, and causing my machine to start swapping. What's the default size?

That said, I haven't seen this happen for the last couple of weeks. Could just be a co-incidence, but I did upgrade the nvidia drivers around then... I'll keep an eye on it for another week.

comment:12 Changed 7 years ago by JYA

Resolution: Works for me
Status: assignedclosed

I've carefully looked over the code and use Apple XCode's memory profiler There's no leak there.

it just fills the cache to whatever the limit is set to (several MB worth)

Note: See TracTickets for help on using tickets.