Opened 9 years ago

Closed 8 years ago

#9345 closed Bug Report (Won't Fix)

mythbackend appears to leak memory

Reported by: udovdh@… Owned by:
Priority: trivial Milestone: unknown
Component: MythTV - General Version: 0.24-fixes
Severity: low Keywords: leak
Cc: Ticket locked: yes

Description

Please have a look at the attached valgrind log of 0.24-fixes svn 27420, built with profile and valgrind enabled.

Attachments (1)

valgrind.log.bz2 (149.9 KB) - added by anonymous 9 years ago.

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by anonymous

Attachment: valgrind.log.bz2 added

comment:1 Changed 9 years ago by stuartm

Milestone: unknown0.25
Owner: set to stuartm
Severity: mediumlow
Status: newaccepted
Ticket locked: set

comment:2 Changed 9 years ago by beirdo

==29663== LEAK SUMMARY:
==29663==    definitely lost: 1,056 bytes in 10 blocks
==29663==    indirectly lost: 44,134 bytes in 304 blocks
==29663==      possibly lost: 695,913 bytes in 7,016 blocks
==29663==    still reachable: 44,373,186 bytes in 4,993 blocks
==29663==         suppressed: 0 bytes in 0 blocks

This is the summary at the end of the log. No appreciable memory leak. 45kB between definitely lost and indirectly lost. I would not expect this to be treated with any high priority.

comment:3 Changed 9 years ago by stuartm

Priority: minormajor

comment:4 Changed 8 years ago by stuartm

Milestone: 0.25unknown
Owner: stuartm deleted
Status: acceptednew

comment:5 Changed 8 years ago by beirdo

Priority: majortrivial

comment:6 Changed 8 years ago by beirdo

Here are the highlights of the log:

==29663== 7,258 (144 direct, 7,114 indirect) bytes in 1 blocks are definitely lost in loss record 5,138 of 5,194
==29663==    at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
==29663==    by 0x3F6A968F91: QObject::QObject(QObject*) (in /usr/lib64/libQtCore.so.4.6.3)
==29663==    by 0x4E34372: Setting::Setting(Storage*) (settings.h:81)
==29663==    by 0x4E3ABF5: RecordingType::RecordingType(RecordingProfile const&) (settings.h:259)
==29663==    by 0x4E32F79: RecordingProfile::loadByID(int) (recordingprofile.cpp:1295)
==29663==    by 0x4E2E969: RecordingProfile::loadByType(QString const&, QString const&) (recordingprofile.cpp:1356)
==29663==    by 0x52CE861: load_profile(QString, void*, RecordingInfo*, RecordingProfile&) (tv_rec.cpp:4012)
==29663==    by 0x52D312B: TVRec::SetupDTVSignalMonitor(bool) (tv_rec.cpp:1973)
==29663==    by 0x5241EC4: SignalMonitor::IsChannelTuned() (signalmonitor.cpp:528)
==29663==    by 0x53DD94C: DVBSignalMonitor::UpdateValues() (dvbsignalmonitor.cpp:235)
==29663==    by 0x52439A0: SignalMonitor::MonitorLoop() (signalmonitor.cpp:322)
==29663==    by 0x52407B9: SignalMonitor::SpawnMonitorLoop(void*) (signalmonitor.cpp:355)
==29663== 
==29663== 7,300 (192 direct, 7,108 indirect) bytes in 1 blocks are definitely lost in loss record 5,139 of 5,194
==29663==    at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
==29663==    by 0x3F6A86F532: ??? (in /usr/lib64/libQtCore.so.4.6.3)
==29663==    by 0x3F6A870F3A: ??? (in /usr/lib64/libQtCore.so.4.6.3)
==29663==    by 0x3F6A968FC1: QObject::QObject(QObject*) (in /usr/lib64/libQtCore.so.4.6.3)
==29663==    by 0x4E3154D: RecordingProfile::RecordingProfile(QString) (recordingprofile.cpp:1174)
==29663==    by 0x52D30C4: TVRec::SetupDTVSignalMonitor(bool) (tv_rec.cpp:1972)
==29663==    by 0x5241EC4: SignalMonitor::IsChannelTuned() (signalmonitor.cpp:528)
==29663==    by 0x53DD94C: DVBSignalMonitor::UpdateValues() (dvbsignalmonitor.cpp:235)
==29663==    by 0x52439A0: SignalMonitor::MonitorLoop() (signalmonitor.cpp:322)
==29663==    by 0x52407B9: SignalMonitor::SpawnMonitorLoop(void*) (signalmonitor.cpp:355)
==29663==    by 0x339C207760: start_thread (in /lib64/libpthread-2.12.1.so)
==29663==    by 0x339BEE14FC: clone (in /lib64/libc-2.12.1.so)
==29663== 
==29663== 7,300 (160 direct, 7,140 indirect) bytes in 1 blocks are definitely lost in loss record 5,140 of 5,194
==29663==    at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
==29663==    by 0x4E31D51: RecordingProfile::RecordingProfile(QString) (recordingprofile.cpp:1208)
==29663==    by 0x52D30C4: TVRec::SetupDTVSignalMonitor(bool) (tv_rec.cpp:1972)
==29663==    by 0x5241EC4: SignalMonitor::IsChannelTuned() (signalmonitor.cpp:528)
==29663==    by 0x53DD94C: DVBSignalMonitor::UpdateValues() (dvbsignalmonitor.cpp:235)
==29663==    by 0x52439A0: SignalMonitor::MonitorLoop() (signalmonitor.cpp:322)
==29663==    by 0x52407B9: SignalMonitor::SpawnMonitorLoop(void*) (signalmonitor.cpp:355)
==29663==    by 0x339C207760: start_thread (in /lib64/libpthread-2.12.1.so)
==29663==    by 0x339BEE14FC: clone (in /lib64/libc-2.12.1.so)
==29663== 
==29663== 7,300 (32 direct, 7,268 indirect) bytes in 1 blocks are definitely lost in loss record 5,141 of 5,194
==29663==    at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
==29663==    by 0x4E35BBD: std::vector<Configurable*, std::allocator<Configurable*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<Configurable**, std::vector<Configurable*, std::allocator<Configurable*> > >, Configurable* const&) (new_allocator.h:89)
==29663==    by 0x79220B5: ConfigurationDialog::addChild(Configurable*) (stl_vector.h:741)
==29663==    by 0x4E32F83: RecordingProfile::loadByID(int) (recordingprofile.cpp:1295)
==29663==    by 0x4E2E969: RecordingProfile::loadByType(QString const&, QString const&) (recordingprofile.cpp:1356)
==29663==    by 0x52CE861: load_profile(QString, void*, RecordingInfo*, RecordingProfile&) (tv_rec.cpp:4012)
==29663==    by 0x52D312B: TVRec::SetupDTVSignalMonitor(bool) (tv_rec.cpp:1973)
==29663==    by 0x5241EC4: SignalMonitor::IsChannelTuned() (signalmonitor.cpp:528)
==29663==    by 0x53DD94C: DVBSignalMonitor::UpdateValues() (dvbsignalmonitor.cpp:235)
==29663==    by 0x52439A0: SignalMonitor::MonitorLoop() (signalmonitor.cpp:322)
==29663==    by 0x52407B9: SignalMonitor::SpawnMonitorLoop(void*) (signalmonitor.cpp:355)
==29663==    by 0x339C207760: start_thread (in /lib64/libpthread-2.12.1.so)
==29663== 
==29663== 15,376 bytes in 4 blocks are indirectly lost in loss record 5,164 of 5,194
==29663==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==29663==    by 0x4F52589: pes_alloc(unsigned int) (pespacket.cpp:331)
==29663==    by 0x53E8836: ProgramMapTable::ProgramMapTable(ProgramMapTable const&) (pespacket.h:86)
==29663==    by 0x53E218B: DVBCam::SetPMT(ChannelBase const*, ProgramMapTable const*) (dvbcam.cpp:307)
==29663==    by 0x4F71010: MPEGStreamData::ProcessPMT(ProgramMapTable const*) (mpegstreamdata.cpp:805)
==29663==    by 0x4F7252C: MPEGStreamData::HandleTables(unsigned int, PSIPTable const&) (mpegstreamdata.cpp:743)
==29663==    by 0x4F8AB99: DVBStreamData::HandleTables(unsigned int, PSIPTable const&) (dvbstreamdata.cpp:227)
==29663==    by 0x4F6E5D0: MPEGStreamData::HandleTSTables(TSPacket const*) (mpegstreamdata.cpp:929)
==29663==    by 0x4F74867: MPEGStreamData::ProcessTSPacket(TSPacket const&) (mpegstreamdata.cpp:1004)
==29663==    by 0x4F64244: MPEGStreamData::ProcessData(unsigned char const*, int) (mpegstreamdata.cpp:954)
==29663==    by 0x53F9C1F: DVBStreamHandler::RunTS() (dvbstreamhandler.cpp:385)
==29663==    by 0x53FB358: run_dvb_stream_handler_thunk(void*) (dvbstreamhandler.cpp:194)
==29663== 
==29663== 15,864 (360 direct, 15,504 indirect) bytes in 5 blocks are definitely lost in loss record 5,165 of 5,194
==29663==    at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
==29663==    by 0x53E217D: DVBCam::SetPMT(ChannelBase const*, ProgramMapTable const*) (dvbcam.cpp:307)
==29663==    by 0x4F71010: MPEGStreamData::ProcessPMT(ProgramMapTable const*) (mpegstreamdata.cpp:805)
==29663==    by 0x4F7252C: MPEGStreamData::HandleTables(unsigned int, PSIPTable const&) (mpegstreamdata.cpp:743)
==29663==    by 0x4F8AB99: DVBStreamData::HandleTables(unsigned int, PSIPTable const&) (dvbstreamdata.cpp:227)
==29663==    by 0x4F6E5D0: MPEGStreamData::HandleTSTables(TSPacket const*) (mpegstreamdata.cpp:929)
==29663==    by 0x4F74867: MPEGStreamData::ProcessTSPacket(TSPacket const&) (mpegstreamdata.cpp:1004)
==29663==    by 0x4F64244: MPEGStreamData::ProcessData(unsigned char const*, int) (mpegstreamdata.cpp:954)
==29663==    by 0x53F9C1F: DVBStreamHandler::RunTS() (dvbstreamhandler.cpp:385)
==29663==    by 0x53FB358: run_dvb_stream_handler_thunk(void*) (dvbstreamhandler.cpp:194)
==29663==    by 0x339C207760: start_thread (in /lib64/libpthread-2.12.1.so)
==29663==    by 0x339BEE14FC: clone (in /lib64/libc-2.12.1.so)

comment:7 Changed 8 years ago by sphery

Resolution: Won't Fix
Status: newclosed

The first four loss records above are duplicates of those fixed by #6734 (in 2e1e2ae2 ), where that fix was reverted to fix #9104 (in 9bfcd4e0 and backported to 0.24-fixes in 2ca5fd80 ). It seems that there's a small leak when the RecordingProfile? settings widget is used (by the recorder) without a ConfigurationGroup? (as is used in the settings pages), since the ConfigurationGroup? does the cleanup. So, without rewriting the old, legacy, Qt-based, not-mythui settings UI, we can't fix the leak (if we fix the leak when RecordingProfile? is used without ConfigurationGroup?, the settings UI will segfault when ConfigurationGroup? tries to clean up its children). Since the old settings code is going to be replaced with either a mythui-based version or an HTTP-based version or both, this will eventually get fixed as part of that rewrite, and in the meantime is small enough that it makes more sense to devote any effort toward the settings rewrite.

And I don't see any obvious issues with the code specified in the last 2 loss records, so I'm closing this as wontfix.

Note: See TracTickets for help on using tickets.