Opened 5 years ago

Last modified 5 years ago

#12053 new Bug Report - Memory Leak

ScreenSaverX11Private::ResetScreenSaver()'s use of myth_system() causes memory leak

Reported by: faginbagin <mythtv@…> Owned by: beirdo
Priority: minor Milestone: unknown
Component: MythTV - MythSystem Version: 0.27-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

After playing a 4 minute video, valgrind reports numerous memory leaks with a stack trace that looks like this:

==4331== 708 (32 direct, 676 indirect) bytes in 1 blocks are definitely lost in loss record 8,952 of 9,574
==4331==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4331==    by 0x8C046F9: QMapData::node_create(QMapData::Node**, int, int) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==4331==    by 0x5F40AE0: QMap<QString, bool>::node_create(QMapData*, QMapData::Node**, QString const&, bool const&) (qmap.h:453)
==4331==    by 0x5F3FC04: QMap<QString, bool>::operator[](QString const&) (qmap.h:534)
==4331==    by 0x6012805: MythSystemLegacy::ProcessFlags(unsigned int) (mythsystemlegacy.cpp:369)
==4331==    by 0x60111ED: MythSystemLegacy::SetCommand(QString const&, QStringList const&, unsigned int) (mythsystemlegacy.cpp:137)
==4331==    by 0x6010A4A: MythSystemLegacy::SetCommand(QString const&, unsigned int) (mythsystemlegacy.cpp:91)
==4331==    by 0x60108B6: MythSystemLegacy::MythSystemLegacy(QString const&, unsigned int) (mythsystemlegacy.cpp:81)
==4331==    by 0x6013653: myth_system(QString const&, unsigned int, unsigned int) (mythsystemlegacy.cpp:517)
==4331==    by 0x6452D00: ScreenSaverX11Private::ResetScreenSaver() (screensaver-x11.cpp:204)
==4331==    by 0x645178D: ScreenSaverX11::resetSlot() (screensaver-x11.cpp:331)
==4331==    by 0x648C4CB: ScreenSaverX11::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_screensaver-x11.cpp:49)

There were 16 such reports adding up to 242,858 bytes:

==4331== 708 (32 direct, 676 indirect) bytes in 1 blocks are definitely lost in loss record 8,952 of 9,574
==4331== 708 (32 direct, 676 indirect) bytes in 1 blocks are definitely lost in loss record 8,953 of 9,574
==4331== 2,124 (96 direct, 2,028 indirect) bytes in 3 blocks are definitely lost in loss record 9,288 of 9,574
==4331== 3,154 (64 direct, 3,090 indirect) bytes in 1 blocks are definitely lost in loss record 9,347 of 9,574
==4331== 3,540 (160 direct, 3,380 indirect) bytes in 5 blocks are definitely lost in loss record 9,361 of 9,574
==4331== 3,540 (160 direct, 3,380 indirect) bytes in 5 blocks are definitely lost in loss record 9,362 of 9,574
==4331== 5,600 (256 direct, 5,344 indirect) bytes in 2 blocks are definitely lost in loss record 9,431 of 9,574
==4331== 6,308 (128 direct, 6,180 indirect) bytes in 2 blocks are definitely lost in loss record 9,443 of 9,574
==4331== 6,308 (128 direct, 6,180 indirect) bytes in 2 blocks are definitely lost in loss record 9,444 of 9,574
==4331== 9,462 (408 direct, 9,054 indirect) bytes in 3 blocks are definitely lost in loss record 9,487 of 9,574
==4331== 11,200 (544 direct, 10,656 indirect) bytes in 4 blocks are definitely lost in loss record 9,508 of 9,574
==4331== 17,508 (432 direct, 17,076 indirect) bytes in 6 blocks are definitely lost in loss record 9,528 of 9,574
==4331== 22,078 (448 direct, 21,630 indirect) bytes in 7 blocks are definitely lost in loss record 9,541 of 9,574
==4331== 29,416 (320 direct, 29,096 indirect) bytes in 10 blocks are definitely lost in loss record 9,545 of 9,574
==4331== 36,432 (1,632 direct, 34,800 indirect) bytes in 12 blocks are definitely lost in loss record 9,549 of 9,574
==4331== 84,772 (7,616 direct, 77,156 indirect) bytes in 28 blocks are definitely lost in loss record 9,560 of 9,574

It is my hope the above log snippets are sufficient information for someone familiar with myth_system to plug the leak. If not, I can provide the valgrind & mythfrontend logs in case someone wants the full details. WRT the mythfrontend log, I did not have -v system enabled, only -v general,playback,vbi --loglevel debug.

Change History (1)

comment:1 Changed 5 years ago by Raymond Wagner

Looks like if myth_system() is called with the RunInBackground? flag, no reference is kept to the internal MythSystemLegacy? object to delete it once the task terminates.

Note: See TracTickets for help on using tickets.