Memory leak in 64bit?

jinx · 7. März 2015

Hi. Is anyone aware of any memory leaks that occur specifically in 64bit? Possibly in the vdr core, vdr-softhddevice, or vdr-eepg? It seems like I recall something about integers being defined in a way thats not 64bit-friendly. Something along the lines of "int" vs. "uintptr_t":

Zitat

A common reason to want an integer type that can hold an architecture's pointer type is to perform integer-specific operations on a pointer, or to obscure the type of a pointer by providing it as an integer "handle".

I've got a bad memory leak in a minimal 64bit setup and it's been a pain trying to figure out what/where the problem actually is.

mini73 · 8. März 2015

I have not seen any memory leaks so far, running a 64 bit system for years. But I don't use eepg. vsr and softhddevice are fine here, but it isn't running 24/7, only for recordings and playbacks.

I here about different problems with eepg, maybe one should review that code first.

Lars

Ulrich Eckhardt · 11. April 2015

I don't know if this is related. I have done some valgrind tests for one of my plugins and found the following output, which seems to be related to softtddevice:

Code

==12508== 18 bytes in 3 blocks are possibly lost in loss record 670 of 2,452
==12508==    at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12508==    by 0x96292E5: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962992C: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962B563: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962BC04: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962B6F5: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962BC04: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962B6F5: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962BC04: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962B6F5: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962BCD8: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x962EBE2: snd_config_update_r (in /usr/lib64/libasound.so.2.0.0)
==12508== 
==12508== 20 bytes in 1 blocks are possibly lost in loss record 746 of 2,452
==12508==    at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12508==    by 0x662E0A9: strdup (in /lib64/libc-2.19.so)
==12508==    by 0x9632CE3: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x9648B54: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x9649175: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x8B15194: AlsaOpenPCM (audio.c:1032)
==12508==    by 0x8B1523C: AlsaInitPCM (audio.c:1057)
==12508==    by 0x8B15ADF: AlsaInit (audio.c:1399)
==12508==    by 0x8B1807E: AudioInit (audio.c:2880)
==12508==    by 0x8B099EB: Start (softhddev.c:3215)
==12508==    by 0x8B02F0D: cPluginSoftHdDevice::Start() (softhddevice.cpp:2764)
==12508==    by 0x513C03: cPluginManager::StartPlugins() (plugin.c:376)
==12508== 
==12508== 20 bytes in 1 blocks are possibly lost in loss record 747 of 2,452
==12508==    at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12508==    by 0x662E0A9: strdup (in /lib64/libc-2.19.so)
==12508==    by 0x9632CE3: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x9637892: ??? (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x96362A2: snd_hctl_open (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x96411C3: snd_mixer_attach (in /usr/lib64/libasound.so.2.0.0)
==12508==    by 0x8B15467: AlsaInitMixer (audio.c:1118)
==12508==    by 0x8B15AE4: AlsaInit (audio.c:1400)
==12508==    by 0x8B1807E: AudioInit (audio.c:2880)
==12508==    by 0x8B099EB: Start (softhddev.c:3215)
==12508==    by 0x8B02F0D: cPluginSoftHdDevice::Start() (softhddevice.cpp:2764)
==12508==    by 0x513C03: cPluginManager::StartPlugins() (plugin.c:376)

Alles anzeigen

johns · 11. April 2015

You can read more about the memory leak here: Etwas frist Speicher VDR, Streamdev, SoftHdDevice, ffmpeg, VDPAU? VDR

tl;dr Its some forever growing list or buffer in cDevice:PlayVideo in VDR core.

Johns

Memory leak in 64bit?

Jetzt mitmachen!

Teilen