Speicherleck in text2skin?

Brougs78 · 13. Januar 2007

Hi!

Könnten text2skin-User bitte mal folgendes Mal testen:

VDR starten (am besten neu starten)
mit "top" oder "htop" auf der Konsole den Speicherverbrauch von VDR beobachten (in der RES-Spalte)
Beim VDR einfach ca. 20 Mal das Menü öffnen und wieder schließen

Ich kann hier einen drastischen Speicheranstieg reproduzieren (mit der CVS-Version von text2skin und text2skin-ext für Enimga). Mit dem Standardskin passiert nichts und VDR braucht immer gleich viel Speicher.

Es scheint so als ob bei jedem Öffnen des Menüs irgendwo Speicher verbraucht aber nicht mehr freigegeben wird. Wenn ich die Kanalliste hoch- und runterzappe passiert auch nichts (bis auf das anfängliche Laden der Logos).

Könnt ihr das reporduzieren? Mit text2skin oder text2skin-ext?

Wie heißt nochmal das Tool um zu anlysieren wo Speicher verbraten wird?
EDIT: Ah genau, das müsste valgrind sein ... werde mal schauen ob ich das ans Laufen bekomme.

Gruß,
Brougs78

Brougs78 · 13. Januar 2007

Hi!

45 Hits und das hat keiner getestet ... wäre ja jetzt nicht wirklich aufwändig ...

Gruß,
Brougs78

Elchi · 13. Januar 2007

Zitat

Ich kann hier einen drastischen Speicheranstieg reproduzieren (mit der CVS-Version von text2skin

Kann ich auch reproduzieren!!

Elchi

Taipan · 13. Januar 2007

:moin,

habs auch getestet - stimmt
Falls Ihr den vdr - Prozess meint der an Größe (Size) zunimmt, das ist hier auch so und er geht auch nicht von alleine wieder runter...

andreas_h · 13. Januar 2007

Kann ich ebenfalls bestätigen. Anstieg unter 'RES' von 28m auf 34m nach 20mailigem auf/zu.

Brougs78 · 13. Januar 2007

Hi!

Ich hatte sogar mal nen Sprung von ca. 30 MB auf über 100 MB! Das ist natürlich nicht so toll.

Habt ihr auch das Problem dass manchmal das Hauptmenü lange braucht bis zum Erscheinen? Deshalb suche ich nämlich nach "Verursachern".

Gruß,
Brougs78

Brougs78 · 13. Januar 2007

Hi!

Hab noch ein wenig geforscht. Das ganze passiert bei plain VDR und auch älteren VDR-Versionen mit dem Standard-Text2skin. Bei jedem Anzeigen eines Menüs (auch Kanalmenü usw. ... da hatte ich mich zu erst geirrt) und bei jedem text2skin-Skin.
Anscheinend wird bei den Menüs irgendwo Speicher alloziert und dann nicht mehr freigegeben. Immer etwa 200 kB ... unabhängig vom Skin.

Gruß,
Brougs78

Brougs78 · 13. Januar 2007

Also ich habe mal versucht mit valgrind etwas herauszubekommen. Habe dazu VDR und text2skin mit "-ggdb -O0 -fno-inline" kompiliert. Allerdings werden nicht alle Speicheradressen aufgelöst und gerade die interessanten Bereiche nicht:

Code

==17081== 2,100 bytes in 1 blocks are definitely lost in loss record 21 of 31
==17081==    at 0x4019B39: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==17081==    by 0x443C0F6: ???
==17081==    by 0x443213E: ???
==17081==    by 0x4440CB0: ???
==17081==    by 0x44406D6: ???
==17081==    by 0x443664D: ???
==17081==    by 0x440F202: ???
==17081==    by 0x440EB24: ???
==17081==    by 0x440E81D: ???
==17081==    by 0x80E86DC: cPluginManager::StartPlugins() (plugin.c:356)
==17081==    by 0x8122FF3: main (vdr.c:616)
==17081== 
==17081== 
==17081== 4,019 (3,396 direct, 623 indirect) bytes in 3 blocks are definitely lost in loss record 23 of 31
==17081==    at 0x4019B39: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==17081==    by 0x440EDC2: ???
==17081==    by 0x440EB24: ???
==17081==    by 0x440E81D: ???
==17081==    by 0x80E86DC: cPluginManager::StartPlugins() (plugin.c:356)
==17081==    by 0x8122FF3: main (vdr.c:616)
==17081== 
==17081== 
==17081== 27,560 bytes in 1 blocks are possibly lost in loss record 26 of 31
==17081==    at 0x40196F9: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==17081==    by 0x80E1611: cBitmap::SetSize(int, int) (osd.c:141)
==17081==    by 0x80E12E7: cBitmap::cBitmap(int, int, int, int, int) (osd.c:104)
==17081==    by 0x442C94D: ???
==17081==    by 0x441CB96: ???
==17081==    by 0x4410276: ???
==17081==    by 0x440F9B9: ???
==17081==    by 0x80D23BC: cDisplayChannel::cDisplayChannel(int, bool) (menu.c:3054)
==17081==    by 0x812394E: main (vdr.c:746)
==17081== 
==17081== 
==17081== 2,982,232 (84,240 direct, 2,897,992 indirect) bytes in 78 blocks are definitely lost in loss record 28 of 31
==17081==    at 0x4019B39: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==17081==    by 0x442C8B7: ???
==17081==    by 0x441CB96: ???
==17081==    by 0x441500F: ???
==17081==    by 0x440FA22: ???
==17081==    by 0x80DF44E: cOsdMenu::cOsdMenu(char const*, int, int, int, int, int) (osdbase.c:90)
==17081==    by 0x80D0B7C: cMenuMain::cMenuMain(eOSState) (menu.c:2783)
==17081==    by 0x8124612: main (vdr.c:887)

Alles anzeigen

Hat da jemand einen Tipp wie ich da noch die "???" vermeiden kann?

anbr · 13. Januar 2007

In diesem Bereich liegen bei mir die Symbol der Bibliothek libc.

Unter Debian ist es die Bibliothek "libc6-dbg" ....

Lustigerweise wirft ein vdr ohne Plugins schon ein leak ...

# libtool --mode=execute valgrind --leak-check=full --show-reachable=yes vdr

Code

==4854== Memcheck, a memory error detector.
==4854== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==4854== Using LibVEX rev 1658, a library for dynamic binary translation.
==4854== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==4854== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==4854== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==4854== For more details, rerun with: -v
==4854==
vdr: error while reading '/video/sources.conf'
==4854==
==4854== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
==4854== malloc/free: in use at exit: 21 bytes in 2 blocks.
==4854== malloc/free: 184 allocs, 182 frees, 30,237 bytes allocated.
==4854== For counts of detected errors, rerun with: -v
==4854== searching for pointers to 2 not-freed blocks.
==4854== checked 480,320 bytes.
==4854==
==4854== 21 bytes in 2 blocks are still reachable in loss record 1 of 1
==4854==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4854==    by 0x422070F: strdup (strdup.c:43)
==4854==    by 0x80F45EC: cPlugin::SetConfigDirectory(char const*) (plugin.c:135)
==4854==    by 0x8138E22: main (vdr.c:522)
==4854==
==4854== LEAK SUMMARY:
==4854==    definitely lost: 0 bytes in 0 blocks.
==4854==      possibly lost: 0 bytes in 0 blocks.
==4854==    still reachable: 21 bytes in 2 blocks.
==4854==         suppressed: 0 bytes in 0 blocks.

Alles anzeigen

anbr · 13. Januar 2007

Hi,

also ein 200k Speicherleak kann ich hier bei einem vanilla VDR 1.4.4 nicht entdecken.
Ich komm nur auf 71bytes die aber vermutlich nicht zyklisch sondern nur einmalig auflaufen.

Code

==4907== Memcheck, a memory error detector.
==4907== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==4907== Using LibVEX rev 1658, a library for dynamic binary translation.
==4907== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==4907== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==4907== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==4907== For more details, rerun with: -v
==4907== 
==4907== My PID = 4907, parent PID = 4906.  Prog and args are:
==4907==    /opt/vdr-1.4/bin/vdr
==4907==    -l
==4907==    1.6
==4907==    -v
==4907==    /video/vdr
==4907==    -L
==4907==    /opt/vdr-1.4/lib
==4907==    -s
==4907==    /opt/vdr-1.4/bin/extb-poweroff.pl
==4907==    -Posdteletext --directory=/dev/shm --max-cache=96
==4907==    -Pdvdselect
==4907==    -Pdvd --dvd=/dev/dvd
==4907==    -Pmuggle -h localhost -u root -p 3306 -n GiantDisc -t/video/mp3/
==4907==    -Pmp3 --mount=/opt/vdr-1.4/bin/mount.sh --cddb=/video/cddb --cache=/var/cache/mp3
==4907==    -Pmplayer --mplayer=/opt/vdr-1.4/bin/mplayer.sh --mount=/opt/vdr-1.4/bin/mount.sh
==4907==    -Pimage --convert=/opt/vdr-1.4/bin/imageplugin.sh --mount=/opt/vdr-1.4/bin/mount.sh
==4907==    -Pradio
==4907==    -Posdpip
==4907==    -Pstreamdev-server --remux=/opt/vdr-1.4/bin/streamdev-remux.sh 
==4907==    -Pscreenshot
==4907==    -Pfemon
==4907==    -Pbeep
==4907==    -Pextb
==4907==    -Pgraphlcd -d gu140x32f -c /var/cache/vdr/graphlcd.conf
==4907==    -r
==4907==    /opt/vdr-1.4/bin/noadatvdr.sh
==4907==    -c
==4907==    /var/cache/vdr
==4907==    -E
==4907==    /var/cache/vdr/epg.data
==4907== 
==5043== Thread 2:
==5043== Conditional jump or move depends on uninitialised value(s)
==5043==    at 0x404F0CC: __pthread_manager (manager.c:128)
==5043==    by 0x4272349: clone (clone.S:119)
==5043== 
==5043== Syscall param clone(child_tidptr) contains uninitialised byte(s)
==5043==    at 0x427233C: clone (clone.S:100)
==5043==    by 0x4272349: clone (clone.S:119)
==4907== Warning: noted but unhandled ioctl 0x6F25 with no size/direction hints
==4907==    This could cause spurious value errors to appear.
==4907==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==4907== Warning: noted but unhandled ioctl 0x6F1D with no size/direction hints
==4907==    This could cause spurious value errors to appear.
==4907==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==4907== Warning: noted but unhandled ioctl 0x6F80 with no size/direction hints
==4907==    This could cause spurious value errors to appear.
==4907==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==5057== 
==5057== Thread 12:
==5057== Conditional jump or move depends on uninitialised value(s)
==5057==    at 0x401D5D3: rawmemchr (mc_replace_strmem.c:536)
==5057==    by 0x4219663: _IO_str_init_static_internal (strops.c:76)
==5057==    by 0x420E8EC: vsscanf (iovsscanf.c:44)
==5057==    by 0x420A2ED: sscanf (sscanf.c:34)
==5057==    by 0x80C5D9C: cLircRemote::Action() (lirc.c:92)
==5057==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==5057==    by 0x404EC50: pthread_start_thread (manager.c:310)
==5057==    by 0x4272349: clone (clone.S:119)
==5053== 
==5053== Thread 8:
==5053== Conditional jump or move depends on uninitialised value(s)
==5053==    at 0x523563C: cExtBLircWatch::Action() (extb_lircwatch.c:95)
==5053==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==5053==    by 0x404EC50: pthread_start_thread (manager.c:310)
==5053==    by 0x4272349: clone (clone.S:119)
==5059== 
==5059== Thread 14:
==5059== Invalid read of size 1
==5059==    at 0x8107DB6: cFrame::cFrame(unsigned char const*, int, eFrameType, int) (ringbuffer.c:344)
==5059==    by 0x4435010: cTxtReceiver::Receive(unsigned char*, int) (txtrecv.c:744)
==5059==    by 0x80A6036: cDevice::Action() (device.c:1203)
==5059==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==5059==    by 0x404EC50: pthread_start_thread (manager.c:310)
==5059==    by 0x4272349: clone (clone.S:119)
==5059==  Address 0x7EB6028 is 0 bytes after a block of size 2,097,152 alloc'd
==5059==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==5059==    by 0x81094A5: cRingBufferLinear::cRingBufferLinear(int, int, bool, char const*) (ringbuffer.c:163)
==5059==    by 0x80A5C0F: cTSBuffer::cTSBuffer(int, int, int) (device.c:1324)
==5059==    by 0x80AAB91: cDvbDevice::OpenDvr() (dvbdevice.c:1188)
==5059==    by 0x80A5F2F: cDevice::Action() (device.c:1192)
==5059==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==5059==    by 0x404EC50: pthread_start_thread (manager.c:310)
==5059==    by 0x4272349: clone (clone.S:119)
==4907== 
==4907== Thread 1:
==4907== Syscall param ioctl(arg) contains uninitialised byte(s)
==4907==    at 0x426B104: ioctl (in /usr/lib/debug/libc-2.3.6.so)
==4907==    by 0x5A97802: GLCD::cDriverGU140X32F::DeInit() (gu140x32f.c:225)
==4907==    by 0x5A6D3C4: cPluginGraphLCD::~cPluginGraphLCD() (plugin.c:82)
==4907==    by 0x80F503C: cDll::~cDll() (plugin.c:160)
==4907==    by 0x8131980: cListBase::Del(cListObject*, bool) (tools.c:1408)
==4907==    by 0x80F41CE: cPluginManager::Shutdown(bool) (plugin.c:473)
==4907==    by 0x813D16C: main (vdr.c:1243)
==4907== 
==4907== Mismatched free() / delete / delete []
==4907==    at 0x401BCBC: operator delete(void*) (vg_replace_malloc.c:244)
==4907==    by 0x51728CF: cPluginRadio::~cPluginRadio() (radio.c:335)
==4907==    by 0x80F503C: cDll::~cDll() (plugin.c:160)
==4907==    by 0x8131980: cListBase::Del(cListObject*, bool) (tools.c:1408)
==4907==    by 0x80F41CE: cPluginManager::Shutdown(bool) (plugin.c:473)
==4907==    by 0x813D16C: main (vdr.c:1243)
==4907==  Address 0x6FBEF48 is 0 bytes inside a block of size 29 alloc'd
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x422070F: strdup (strdup.c:43)
==4907==    by 0x5172F81: cPluginRadio::Start() (radio.c:422)
==4907==    by 0x80F3FE4: cPluginManager::StartPlugins() (plugin.c:356)
==4907==    by 0x8139BAC: main (vdr.c:616)
==4907== 
==4907== Mismatched free() / delete / delete []
==4907==    at 0x401BCBC: operator delete(void*) (vg_replace_malloc.c:244)
==4907==    by 0x51728EB: cPluginRadio::~cPluginRadio() (radio.c:336)
==4907==    by 0x80F503C: cDll::~cDll() (plugin.c:160)
==4907==    by 0x8131980: cListBase::Del(cListObject*, bool) (tools.c:1408)
==4907==    by 0x80F41CE: cPluginManager::Shutdown(bool) (plugin.c:473)
==4907==    by 0x813D16C: main (vdr.c:1243)
==4907==  Address 0x6FBEFE8 is 0 bytes inside a block of size 29 alloc'd
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x422070F: strdup (strdup.c:43)
==4907==    by 0x5172FB3: cPluginRadio::Start() (radio.c:424)
==4907==    by 0x80F3FE4: cPluginManager::StartPlugins() (plugin.c:356)
==4907==    by 0x8139BAC: main (vdr.c:616)
==4907== 
==4907== Mismatched free() / delete / delete []
==4907==    at 0x401BCBC: operator delete(void*) (vg_replace_malloc.c:244)
==4907==    by 0x5172907: cPluginRadio::~cPluginRadio() (radio.c:337)
==4907==    by 0x80F503C: cDll::~cDll() (plugin.c:160)
==4907==    by 0x8131980: cListBase::Del(cListObject*, bool) (tools.c:1408)
==4907==    by 0x80F41CE: cPluginManager::Shutdown(bool) (plugin.c:473)
==4907==    by 0x813D16C: main (vdr.c:1243)
==4907==  Address 0x6FBF038 is 0 bytes inside a block of size 39 alloc'd
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x421390B: vasprintf (vasprintf.c:75)
==4907==    by 0x41FBD8D: asprintf (asprintf.c:37)
==4907==    by 0x5172FEE: cPluginRadio::Start() (radio.c:426)
==4907==    by 0x80F3FE4: cPluginManager::StartPlugins() (plugin.c:356)
==4907==    by 0x8139BAC: main (vdr.c:616)
==4907== 
==4907== Mismatched free() / delete / delete []
==4907==    at 0x401BCBC: operator delete(void*) (vg_replace_malloc.c:244)
==4907==    by 0x5172923: cPluginRadio::~cPluginRadio() (radio.c:338)
==4907==    by 0x80F503C: cDll::~cDll() (plugin.c:160)
==4907==    by 0x8131980: cListBase::Del(cListObject*, bool) (tools.c:1408)
==4907==    by 0x80F41CE: cPluginManager::Shutdown(bool) (plugin.c:473)
==4907==    by 0x813D16C: main (vdr.c:1243)
==4907==  Address 0x6FBF090 is 0 bytes inside a block of size 40 alloc'd
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x421390B: vasprintf (vasprintf.c:75)
==4907==    by 0x41FBD8D: asprintf (asprintf.c:37)
==4907==    by 0x517301F: cPluginRadio::Start() (radio.c:428)
==4907==    by 0x80F3FE4: cPluginManager::StartPlugins() (plugin.c:356)
==4907==    by 0x8139BAC: main (vdr.c:616)
==4907== 
==4907== ERROR SUMMARY: 175 errors from 10 contexts (suppressed: 225 from 8)
==4907== malloc/free: in use at exit: 2,113,739 bytes in 23 blocks.
==4907== malloc/free: 496,593 allocs, 496,570 frees, 58,064,430 bytes allocated.
==4907== For counts of detected errors, rerun with: -v
==4907== searching for pointers to 23 not-freed blocks.
==4907== checked 10,966,720 bytes.
==4907== 
==4907== 
==4907== 4 bytes in 1 blocks are definitely lost in loss record 1 of 15
==4907==    at 0x401CB31: operator new(unsigned) (vg_replace_malloc.c:163)
==4907==    by 0x45BE96F: ???
==4907==    by 0x45D76C1: ???
==4907==    by 0x45AAB30: ???
==4907==    by 0x400B7F4: call_init (in /lib/ld-2.3.6.so)
==4907==    by 0x400B920: _dl_init (in /lib/ld-2.3.6.so)
==4907==    by 0x42A4696: dl_open_worker (dl-open.c:504)
==4907==    by 0x400B44E: _dl_catch_error (in /lib/ld-2.3.6.so)
==4907==    by 0x42A3E4E: _dl_open (dl-open.c:577)
==4907==    by 0x409BD8D: dlopen_doit (dlopen.c:59)
==4907==    by 0x400B44E: _dl_catch_error (in /lib/ld-2.3.6.so)
==4907==    by 0x409C1BC: _dlerror_run (dlerror.c:162)
==4907== 
==4907== 
==4907== 9 bytes in 1 blocks are definitely lost in loss record 2 of 15
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x422070F: strdup (strdup.c:43)
==4907==    by 0x4458ADC: ???
==4907==    by 0x4458709: ???
==4907==    by 0x80F4ED3: cDll::Load(bool) (plugin.c:248)
==4907==    by 0x80F4FBB: cPluginManager::LoadPlugins(bool) (plugin.c:325)
==4907==    by 0x8138DE8: main (vdr.c:514)
==4907== 
==4907== 
==4907== 16 bytes in 1 blocks are still reachable in loss record 3 of 15
==4907==    at 0x401B6CA: calloc (vg_replace_malloc.c:279)
==4907==    by 0x409C227: _dlerror_run (dlerror.c:140)
==4907==    by 0x409BD20: dlopen@@GLIBC_2.1 (dlopen.c:78)
==4907==    by 0x80F4BCC: cDll::Load(bool) (plugin.c:194)
==4907==    by 0x80F4FBB: cPluginManager::LoadPlugins(bool) (plugin.c:325)
==4907==    by 0x8138DE8: main (vdr.c:514)
==4907== 
==4907== 
==4907== 26 bytes in 1 blocks are indirectly lost in loss record 4 of 15
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x421390B: vasprintf (vasprintf.c:75)
==4907==    by 0x41FBD8D: asprintf (asprintf.c:37)
==4907==    by 0x443667E: ???
==4907==    by 0x44367E5: ???
==4907==    by 0x4436967: ???
==4907==    by 0x4436C0F: ???
==4907==    by 0x8123C20: cStatus::MsgChannelSwitch(cDevice const*, int) (status.c:29)
==4907==    by 0x80A7BD1: cDevice::SetChannel(cChannel const*, bool) (device.c:697)
==4907==    by 0x80A7C53: cDevice::SwitchChannel(cChannel const*, bool) (device.c:563)
==4907==    by 0x8092B50: cChannels::SwitchTo(int) (channels.c:1024)
==4907==    by 0x8139EC7: main (vdr.c:648)
==4907== 
==4907== 
==4907== 58 (32 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 15
==4907==    at 0x401CB31: operator new(unsigned) (vg_replace_malloc.c:163)
==4907==    by 0x4434C4E: ???
==4907==    by 0x442F8FB: ???
==4907==    by 0x80F4ED3: cDll::Load(bool) (plugin.c:248)
==4907==    by 0x80F4FBB: cPluginManager::LoadPlugins(bool) (plugin.c:325)
==4907==    by 0x8138DE8: main (vdr.c:514)
==4907== 
==4907== 
==4907== 45 bytes in 2 blocks are still reachable in loss record 6 of 15
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x421390B: vasprintf (vasprintf.c:75)
==4907==    by 0x812C519: cThread::SetDescription(char const*, ...) (thread.c:234)
==4907==    by 0x80A5BBB: cTSBuffer::cTSBuffer(int, int, int) (device.c:1320)
==4907==    by 0x80AAB91: cDvbDevice::OpenDvr() (dvbdevice.c:1188)
==4907==    by 0x80A5F2F: cDevice::Action() (device.c:1192)
==4907==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==4907==    by 0x404EC50: pthread_start_thread (manager.c:310)
==4907==    by 0x4272349: clone (clone.S:119)
==4907== 
==4907== 
==4907== 64 bytes in 1 blocks are still reachable in loss record 7 of 15
==4907==    at 0x401CB31: operator new(unsigned) (vg_replace_malloc.c:163)
==4907==    by 0x80AAB6A: cDvbDevice::OpenDvr() (dvbdevice.c:1188)
==4907==    by 0x80A5F2F: cDevice::Action() (device.c:1192)
==4907==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==4907==    by 0x404EC50: pthread_start_thread (manager.c:310)
==4907==    by 0x4272349: clone (clone.S:119)
==4907== 
==4907== 
==4907== 83 bytes in 5 blocks are still reachable in loss record 8 of 15
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x422070F: strdup (strdup.c:43)
==4907==    by 0x80F45EC: cPlugin::SetConfigDirectory(char const*) (plugin.c:135)
==4907==    by 0x8138E22: main (vdr.c:522)
==4907== 
==4907== 
==4907== 128 bytes in 1 blocks are still reachable in loss record 9 of 15
==4907==    at 0x401B6CA: calloc (vg_replace_malloc.c:279)
==4907==    by 0x4052527: pthread_setspecific (specific.c:150)
==4907==    by 0x409C25B: _dlerror_run (dlerror.c:149)
==4907==    by 0x409BD20: dlopen@@GLIBC_2.1 (dlopen.c:78)
==4907==    by 0x80F4BCC: cDll::Load(bool) (plugin.c:194)
==4907==    by 0x80F4FBB: cPluginManager::LoadPlugins(bool) (plugin.c:325)
==4907==    by 0x8138DE8: main (vdr.c:514)
==4907== 
==4907== 
==4907== 136 bytes in 2 blocks are possibly lost in loss record 10 of 15
==4907==    at 0x401B6CA: calloc (vg_replace_malloc.c:279)
==4907==    by 0x400E188: allocate_dtv (in /lib/ld-2.3.6.so)
==4907==    by 0x400E214: _dl_allocate_tls_storage (in /lib/ld-2.3.6.so)
==4907==    by 0x400E257: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==4907==    by 0x40513BB: __pthread_initialize_manager (pthread.c:667)
==4907==    by 0x4051826: pthread_create@@GLIBC_2.1 (pthread.c:830)
==4907==    by 0x812C36B: cThread::Start() (thread.c:256)
==4907==    by 0x5239E14: ???
==4907==    by 0x523881D: ???
==4907==    by 0x522BD4B: ???
==4907==    by 0x522BDB8: ???
==4907==    by 0x80F4C15: cDll::Load(bool) (plugin.c:200)
==4907== 
==4907== 
==4907== 220 bytes in 1 blocks are still reachable in loss record 11 of 15
==4907==    at 0x401CB31: operator new(unsigned) (vg_replace_malloc.c:163)
==4907==    by 0x80A5BE0: cTSBuffer::cTSBuffer(int, int, int) (device.c:1324)
==4907==    by 0x80AAB91: cDvbDevice::OpenDvr() (dvbdevice.c:1188)
==4907==    by 0x80A5F2F: cDevice::Action() (device.c:1192)
==4907==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==4907==    by 0x404EC50: pthread_start_thread (manager.c:310)
==4907==    by 0x4272349: clone (clone.S:119)
==4907== 
==4907== 
==4907== 2,064 bytes in 2 blocks are still reachable in loss record 12 of 15
==4907==    at 0x401CB31: operator new(unsigned) (vg_replace_malloc.c:163)
==4907==    by 0x80C2796: cFont::SetFont(eDvbFont, void const*) (font.c:119)
==4907==    by 0x80C287B: cFont::GetFont(eDvbFont) (font.c:129)
==4907==    by 0x8120CF3: cSkinSTTNGDisplayChannel::cSkinSTTNGDisplayChannel(bool) (skinsttng.c:156)
==4907==    by 0x8121BB2: cSkinSTTNG::DisplayChannel(bool) (skinsttng.c:1099)
==4907==    by 0x80CD8DB: cDisplayChannel::cDisplayChannel(int, bool) (menu.c:3054)
==4907==    by 0x813A618: main (vdr.c:746)
==4907== 
==4907== 
==4907== 5,600 bytes in 2 blocks are possibly lost in loss record 13 of 15
==4907==    at 0x401B58B: memalign (vg_replace_malloc.c:332)
==4907==    by 0x400E1E6: _dl_allocate_tls_storage (in /lib/ld-2.3.6.so)
==4907==    by 0x400E257: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==4907==    by 0x40513BB: __pthread_initialize_manager (pthread.c:667)
==4907==    by 0x4051826: pthread_create@@GLIBC_2.1 (pthread.c:830)
==4907==    by 0x812C36B: cThread::Start() (thread.c:256)
==4907==    by 0x5239E14: ???
==4907==    by 0x523881D: ???
==4907==    by 0x522BD4B: ???
==4907==    by 0x522BDB8: ???
==4907==    by 0x80F4C15: cDll::Load(bool) (plugin.c:200)
==4907==    by 0x80F4FBB: cPluginManager::LoadPlugins(bool) (plugin.c:325)
==4907== 
==4907== 
==4907== 2,097,152 bytes in 1 blocks are still reachable in loss record 15 of 15
==4907==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==4907==    by 0x81094A5: cRingBufferLinear::cRingBufferLinear(int, int, bool, char const*) (ringbuffer.c:163)
==4907==    by 0x80A5C0F: cTSBuffer::cTSBuffer(int, int, int) (device.c:1324)
==4907==    by 0x80AAB91: cDvbDevice::OpenDvr() (dvbdevice.c:1188)
==4907==    by 0x80A5F2F: cDevice::Action() (device.c:1192)
==4907==    by 0x812C460: cThread::StartThread(cThread*) (thread.c:244)
==4907==    by 0x404EC50: pthread_start_thread (manager.c:310)
==4907==    by 0x4272349: clone (clone.S:119)
==4907== 
==4907== LEAK SUMMARY:
==4907==    definitely lost: 45 bytes in 3 blocks.
==4907==    indirectly lost: 26 bytes in 1 blocks.
==4907==      possibly lost: 5,736 bytes in 4 blocks.
==4907==    still reachable: 2,099,772 bytes in 14 blocks.
==4907==         suppressed: 8,160 bytes in 1 blocks.

Alles anzeigen

wirbel · 13. Januar 2007

Du hattest doch gar kein text2skin geladen laut der Ausgabe.

anbr · 13. Januar 2007

Zitat

Original von wirbel
Du hattest doch gar kein text2skin geladen laut der Ausgabe.

Ja, ich weiss aber Brougs78 hat gesagt, das dieses Speicherleak auch in den Standardskin auftritt, was ich erstmal nicht reproduzieren kann.

Aber ich teste gerade weiter. Das störende ist nur das der VDR mit valgrind sehr sehr träge reagiert.

wirbel · 13. Januar 2007

Er schrieb Standard-Text2skin. Also vermutlich non-cvs.

wirbel · 13. Januar 2007

Er schrieb Standard-Text2skin. Also vermutlich non-cvs.

_Frank_ · 13. Januar 2007

Hi,

Zitat

Original von Brougs78
Mit dem Standardskin passiert nichts und VDR braucht immer gleich viel Speicher.

Brougs78:

mal eine Frage: hast Du mal ausprobiert, ob das mit Verwendung von Imlib und ImageMagick auftritt?

Ich hatte doch mal einen Patch für OsdImage erstellt, da bekam ich bei einer Funktion von ImageMagick steigenden Speicherbedarf, den ich mir nicht erklären konnte. Zumindest war mir nichts eingefallen, wie ich den hätte wieder freigeben sollen.

Kann sein, daß das jetzt nichts zur Klärung beiträgt, war nur so ein Gedanke.

Gruß
Frank

vdrchuck · 13. Januar 2007

Zitat

Original von Brougs78
45 Hits und das hat keiner getestet ... wäre ja jetzt nicht wirklich aufwändig ...

Dies lässt sich auch hier bei mir reproduzieren!

Zitat

Original von _Frank_
mal eine Frage: hast Du mal ausprobiert, ob das mit Verwendung von Imlib und ImageMagick auftritt?

Text2skin ist bei mir nur mit ImageMagick kompiliert.

Gruß,
Chuck

armageddon · 13. Januar 2007

Hier nur mit Imlib übersetzt, selbes verhalten.

Brougs78 · 13. Januar 2007

Hi!

@Hulk: Nein ich meinte mit Standard-text2skin, also schon text2skin vom CVS aber ohne die Extensions für Enigma, also ohne den Patch von mir.

Bei Debian kannst du die Debug-Symbole für libc nachladen? Scheint ein schöner Vorteil zu sein denn unter Gentoo finde ich da nichts ... da müsste ich libc wohl mit Debug-Symoblen kompilieren ... ist mir auf der langsamen Mühle zu aufwändig.

Noch ne Frage: Warum rufst du das ganze mit libtool auf?

@Frank: Ja mit imlib passiert das auch. Da gibts glaube ich auch ein Speicherleck aber das dürfte nicht so dramatisch sein denn ich denke die ganzen Bilder sollten im Speicher liegen sobald sie das erste Mal geladen wurden, donn sollte das Leck nur einmal auftreten ...

Gruß,
Brougs78

anbr · 14. Januar 2007

Zitat

Original von Brougs78
Noch ne Frage: Warum rufst du das ganze mit libtool auf?

Hast recht, ist nicht notwendig, diente nur die um die lokalen Bibliotheken (Plugins) zu nutzen, aber der VDR hat ja ehe seinen eigenen Parameter für das Pluginsverzeichnis.
Man sollte sich nie voll auf Beispiele aus dem Netz verlassen.

Brougs78 · 14. Januar 2007

Hi Hulk!

War nicht als Kritik gemeint ... wusste nur wirklich nicht wozu das gut ist. Vielleicht braucht man es ja. Kenne mich da nicht so aus.

Gruß,
Brougs78

Speicherleck in text2skin?

Jetzt mitmachen!

Teilen