VLC Memory leak problem

[CrazyBuntu]

I am having an unbelievable stupid problem with VLC to which I don't have with VLS.

I have 2 PCI DVB-T cards (Hauppauge) which have 2 tuners each card and I am streaming 4 channels from x4 different DVB-T frequencies. If I stream more than 1 channel per frequency, the server shuts down after an hour!
No Matter what I do I can't stop this from happening because there seems to be a memory leak resulting in the VLC process chewing up around about 200K every 5 seconds.
It doesn't take long before the server stops the VLC process because there is no more memory left!
I check this using the command "top" as you will see VLC at the top of the process list because its chewing up the most resources. I've also got the server churning out statistics and graphics from my zabbix monitoring server and I can literally see the memory getting less on a downward trend that only stops when there is no more free mem left!

CPU running is a Intel Duo 2GHz and memory is 2GB running on Ubuntu Server 8.10
No other processes are running except for kernel etc... I haven't got gnome or kde or any x interface. just plain server setup.

Here is the vlc command that I am using:
cvlc -vvv --color --ttl=12 --programs xxx dvb-t://adapter=0:frequency=yyyyyyyyy:bandwidth=8 --sout='#duplicate{dst=standard{dst=239.255.1.1:1234},select="program=xxx"}' --sout-standard-access-udp --sout-standard-mux=ts

Note:
xxx = the program ID.
yyyyyyyyy = Transmission/transponder Frequency


If I use VLS (on the exact same server and with broadcasting ALL channels on each frequency), I never have this problem and its happily running all day everyday without ever failing.
But I don't want to use VLS anymore, I need to use VLC due to certain features I want to implement.

I've read on some really old posts in this forum that people have mentioned this memory leak but no one seems to believe, yet I have never seen someone actually try live streaming with VLC for more than a few hours without any memory leaks. There is NO problem with VLS!

I believe it has been done and people are doing it but I just can't understand why I am having this problem, so if anyone has experienced this and has a solution to this, I would greatly appreciate it if they could tell me how they are able to make VLC run continuously WITHOUT having the memory leak. thus providing the live streaming channels to continuously stream in the network without the need EVER to reboot due to memory leak or something related to VLC, in any case.

This is URGENT and quite important, and I'm quite desperate to get this going as I am about to offer money for a resolution.

Please help

[Rémi Denis-Courmont]

This is a bug. Please check with valgrind where the leak is.

[Beardless2]

any progress on this? This is very important to me too, does anyone know of a way to slow down the leak if a fix is not ready?

[sanitariu]

Hello,
i have the same problem.
Using dvb-s.
Usually it takes 30-40MB and runs for about 15-20 hours then it starts eating memory, until it eats all my 1024MB memory then kernel kills it.
I tried valgrind but it did not detect anything or I run it wrong ?

killall -9 vlc;valgrind -v --log-file=valgrind.log cvlc -I dummy --vlm-conf dvb1stream.conf --no-stats

Any help how i can catch it ?
Is it possible for the leak to be in libdvbpsi ?

[Rémi Denis-Courmont]

Any help how i can catch it ?
Is it possible for the leak to be in libdvbpsi ?

Provide a backtrace of the leaked region with valgrind. And yes, who knows.

[sanitariu]

Hello,
seems like running valgrind with vlc + vlm does not work correctly.
I do not have log although i am running with
valgrind -v --leak-check=full --log-file=valgrind.log cvlc -I dummy --vlm-conf dvb1stream.conf --no-stats
Running vlc instead cvlc does provide log but i am unable to watch anything normally.
Anyway running the first variant after some hours i got
"libdvbpsi error (misc PSI): Bad CRC_32 (0xf3879f2c) !!!"
If you narrow me how and what to run exactly i will provide you with more info.
I also run cppcheck on vlc-git and it gives a lot of mem leaks.

[CrazyBuntu]

Sanitariu,
How did you end up with this ???
Did you find the exact cause of memory leak?
If yes, did you submit bug report?

I am now trying same thing as you but I will do it on VLC RC3 1.0.0 because I have a feeling this damn problem (that has existed since I can remember) will be resolved very soon.
I will be issuing my command as:
valgrind --tool=memcheck --leak-check=yes vlc ................................

Also, I too have noticed the libdvbpsi errors many times. In fact when I look back at the logs, I can remember seeing these errors, every so often. In my area (Australia, NSW) I get a lot of these errors on fridays and saturday mornings. It sounds silly but its true. No matter what day/time I start the process, reboot the server etc... I always get these errors once a week on friday and saturday. I think this is from the broadcaster, probably doing a garbage dump of some sort and vlc happens to pick it up and doesn't know what to do with the excess data or errors, which probably effects it in the form of a memleak???

In any case, I shall follow this closely now that I have some time. I am just installing RC3 and will post the output here, if I get it going with DVB-S and DVB-T.

[CrazyBuntu]

Update:

Due to the fact that I still cannot stream from VLC RC3 1.0.0, I've decided to perform a test on VLC 0.9.9a
So I have a server with a couple of DVB-S cards, connected to a C-Band LNB/Dish.

Now I have some very interesting output from Valgrind!
I ran the test only for 6 hours because any longer, I would have lost access to the server due to vlc and valgrind consuming all of the 4GB of RAM !!! (which it did very eagerly I must add)

Here is the initiation string:
----------------------------------------------------------
algrind --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes /usr/bin/vlc dvb:// --dvb-adapter=0 --dvb-frequency=4000000 --dvb-voltage=18 --dvb-srate=28125000 --ts-es-id-pid -vvv --ttl 12 --programs 1,3,4,9,10,11,15,30,60,6,7,8,14,16,18,23,24,25 --intf dummy --sout='#duplicate{dst=standard{access=udp,mux=ts,dst=239.250.1.1:1234},select="program=1",dst=standard{access=udp,mux=ts,dst=239.250.1.2:1234},select="program=3",
dst=standard{access=udp,mux=ts,dst=239.250.1.3:1234},select="program=4",dst=standard{access=udp,mux=ts,dst=239.250.1.4:1234},select="program=9",dst=standard{acce
ss=udp,mux=ts,dst=239.250.1.5:1234},select="program=10",dst=standard{access=udp,mux=ts,dst=239.250.1.6:1234},select="program=11",dst=standard{access=udp,mux=ts,
dst=239.250.1.7:1234},select="program=15",dst=standard{access=udp,mux=ts,dst=239.250.1.8:1234},select="program=30",dst=standard{access=udp,mux=ts,dst=239.250.1.9
:1234},select="program=60",dst=standard{access=udp,mux=ts,dst=239.250.1.10:1234},select="program=6",dst=standard{access=udp,mux=ts,dst=239.250.1.11:1234},select="
program=7",dst=standard{access=udp,mux=ts,dst=239.250.1.12:1234},select="program=8",dst=standard{access=udp,mux=ts,dst=239.250.1.13:1234},select="program=14",dst
=standard{access=udp,mux=ts,dst=239.250.1.14:1234},select="program=16",dst=standard{access=udp,mux=ts,dst=239.250.1.15:1234},select="program=18",dst=standard{acc
ess=udp,mux=ts,dst=239.250.1.16:1234},select="program=23",dst=standard{access=udp,mux=ts,dst=239.250.1.17:1234},select="program=24",}'
----------------------------------------------------------

And here is the Valgrind output:
----------------------------------------------------------
==3835==
==3835== ERROR SUMMARY: 55 errors from 3 contexts (suppressed: 544 from 3)
==3835== malloc/free: in use at exit: 18,622 bytes in 151 blocks.
==3835== malloc/free: 314,116,359 allocs, 314,116,208 frees, 169,024,833,892 bytes allocated.
==3835== For counts of detected errors, rerun with: -v
==3835== searching for pointers to 151 not-freed blocks.
==3835== checked 244,064 bytes.
==3835==
==3835== Thread 1:
==3835==
==3835== 24 bytes in 1 blocks are still reachable in loss record 1 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5ABD561: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABD788: dbus_bus_register (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDC86: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 24 bytes in 2 blocks are still reachable in loss record 2 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x4C27A37: realloc (vg_replace_malloc.c:429)
==3835== by 0x5AD7384: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABD511: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABD788: dbus_bus_register (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDC86: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 24 bytes in 1 blocks are still reachable in loss record 3 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5ACEADA: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC0E73: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B42: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 56 bytes in 1 blocks are still reachable in loss record 4 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x400D0CF: (within /lib/ld-2.9.so)
==3835== by 0x4013534: (within /lib/ld-2.9.so)
==3835== by 0x400E8C5: (within /lib/ld-2.9.so)
==3835== by 0x4012DBA: (within /lib/ld-2.9.so)
==3835== by 0x5651A5F: (within /lib/libc-2.9.so)
==3835== by 0x400E8C5: (within /lib/ld-2.9.so)
==3835== by 0x5651BC6: __libc_dlopen_mode (in /lib/libc-2.9.so)
==3835== by 0x53237BB: pthread_cancel_init (in /lib/libpthread-2.9.so)
==3835== by 0x5320227: pthread_cancel (in /lib/libpthread-2.9.so)
==3835== by 0xCDDED9C: ???
==3835== by 0x50C59D1: __module_Unneed (in /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 72 bytes in 1 blocks are indirectly lost in loss record 5 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x50DAA9C: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DB442: __var_Get (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5092D79: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5093280: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50CC605: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x531B3B9: start_thread (in /lib/libpthread-2.9.so)
==3835== by 0x5615FCC: clone (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 384 (24 direct, 360 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x50DA9C6: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DB442: __var_Get (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5092D79: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5093280: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50CC605: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x531B3B9: start_thread (in /lib/libpthread-2.9.so)
==3835== by 0x5615FCC: clone (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 32 bytes in 1 blocks are still reachable in loss record 7 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5EF933F: (within /lib/libdl-2.9.so)
==3835== by 0x5EF8EC0: dlopen (in /lib/libdl-2.9.so)
==3835== by 0x50CBFF8: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50C5A34: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50C674B: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50C6666: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50C70D9: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50652F3: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 42 bytes in 1 blocks are still reachable in loss record 8 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ADBBA9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD540E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5562: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835==
==3835==
==3835== 48 bytes in 1 blocks are still reachable in loss record 9 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5AC0D4C: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B42: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 48 bytes in 1 blocks are still reachable in loss record 10 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5AC0D3B: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B42: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 56 bytes in 1 blocks are still reachable in loss record 11 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5ACA367: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD52B6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5562: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835==
==3835==
==3835== 62 bytes in 8 blocks are indirectly lost in loss record 12 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x9B07A7F: ???
==3835== by 0x9A8A5A4: ???
==3835== by 0x9A89DE7: ???
==3835== by 0x9A91D8C: ???
==3835== by 0x9855E7B: ???
==3835== by 0x50C5F34: __module_Need (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DE46F: __xml_Create (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x9648401: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50930FF: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x509320F: __input_Read (in /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 64 bytes in 1 blocks are still reachable in loss record 13 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ACE917: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ACEAFC: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC0E73: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B42: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 80 bytes in 2 blocks are definitely lost in loss record 14 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x9B03E4A: ???
==3835== by 0x9B03938: ???
==3835== by 0x9A91D74: ???
==3835== by 0x9855E7B: ???
==3835== by 0x50C5F34: __module_Need (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DE46F: __xml_Create (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x9648401: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50930FF: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x509320F: __input_Read (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5075698: (within /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 80 bytes in 2 blocks are still reachable in loss record 15 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5AD006D: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD52E6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5562: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835==
==3835==
==3835== 96 bytes in 2 blocks are still reachable in loss record 16 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ADCBDA: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD419D: dbus_threads_init (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5065687: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 104 bytes in 1 blocks are definitely lost in loss record 17 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x9B03DFA: ???
==3835== by 0x9B5E5F6: ???
==3835== by 0x9A8DE4F: ???
==3835== by 0x9A8E0AB: ???
==3835== by 0x9A92505: ???
==3835== by 0x9B46F04: ???
==3835== by 0x9B47149: ???
==3835== by 0x9855F3E: ???
==3835== by 0x9648418: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50930FF: (within /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 105 bytes in 5 blocks are still reachable in loss record 18 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5AD8448: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDDC4: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 120 bytes in 1 blocks are still reachable in loss record 19 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5AD408C: dbus_threads_init (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5065687: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 120 bytes in 3 blocks are still reachable in loss record 20 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5ADA4A3: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD8E54: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD8EBB: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD8F28: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AB9BBA: dbus_parse_address (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2ADE: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 120 bytes in 5 blocks are still reachable in loss record 21 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ADA412: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDD73: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 128 bytes in 2 blocks are still reachable in loss record 22 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5AD6FAB: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5516: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 128 bytes in 1 blocks are definitely lost in loss record 23 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x58AD69F: libhal_ctx_new (in /usr/lib/libhal.so.1.0.0)
==3835== by 0x5065384: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 152 bytes in 7 blocks are still reachable in loss record 24 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ADBBFB: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD54AE: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 192 bytes in 4 blocks are still reachable in loss record 25 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5AC3B7D: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABC19D: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABC249: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5444: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5562: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 224 bytes in 1 blocks are still reachable in loss record 26 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5AD5497: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 224 bytes in 2 blocks are still reachable in loss record 27 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5AD7EB9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2D77: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 240 bytes in 1 blocks are still reachable in loss record 28 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5ABC0C9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABC249: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5444: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5562: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835==
==3835==
==3835== 256 bytes in 1 blocks are still reachable in loss record 29 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5AC0D84: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B42: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 288 bytes in 1 blocks are indirectly lost in loss record 30 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x50DAA8B: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DB442: __var_Get (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5092D79: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5093280: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50CC605: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x531B3B9: start_thread (in /lib/libpthread-2.9.so)
==3835== by 0x5615FCC: clone (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 320 bytes in 8 blocks are indirectly lost in loss record 31 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x9A8A5BE: ???
==3835== by 0x9A89DE7: ???
==3835== by 0x9A91D8C: ???
==3835== by 0x9855E7B: ???
==3835== by 0x50C5F34: __module_Need (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DE46F: __xml_Create (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x9648401: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50930FF: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x509320F: __input_Read (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5075698: (within /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 676 bytes in 38 blocks are definitely lost in loss record 32 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x55B09A1: strdup (in /lib/libc-2.9.so)
==3835== by 0x1C57E992: ???
==3835== by 0x102111CA: ???
==3835== by 0x1020F1D7: ???
==3835== by 0x1C57D3CA: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5093290: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50CC605: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x531B3B9: start_thread (in /lib/libpthread-2.9.so)
==3835== by 0x5615FCC: clone (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 760 bytes in 5 blocks are still reachable in loss record 33 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ACA0C6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ACD516: dbus_message_new_signal (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC0E36: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B42: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 782 (400 direct, 382 indirect) bytes in 1 blocks are definitely lost in loss record 34 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x9A89D2F: ???
==3835== by 0x9A91D8C: ???
==3835== by 0x9855E7B: ???
==3835== by 0x50C5F34: __module_Need (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50DE46F: __xml_Create (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x9648401: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50930FF: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x509320F: __input_Read (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5075698: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5073B41: (within /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 408 bytes in 1 blocks are still reachable in loss record 35 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x401332B: (within /lib/ld-2.9.so)
==3835== by 0x4014B07: (within /lib/ld-2.9.so)
==3835== by 0x40154ED: (within /lib/ld-2.9.so)
==3835== by 0x400E8C5: (within /lib/ld-2.9.so)
==3835== by 0x5EF92CB: (within /lib/libdl-2.9.so)
==3835== by 0x5EF900E: dlclose (in /lib/libdl-2.9.so)
==3835== by 0x50C5B7F: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50C6B08: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50633AA: libvlc_InternalDestroy (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E333C8: libvlc_release (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FEB: (within /usr/bin/vlc)
==3835==
==3835==
==3835== 512 bytes in 1 blocks are definitely lost in loss record 36 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x50C4057: block_Alloc (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x1C57C907: ???
==3835== by 0x1C57D8E8: ???
==3835== by 0x508FC00: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x5093290: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x50CC605: (within /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x531B3B9: start_thread (in /lib/libpthread-2.9.so)
==3835== by 0x5615FCC: clone (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 1,008 bytes in 18 blocks are still reachable in loss record 37 of 40
==3835== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==3835== by 0x5ADCA3A: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD40B1: dbus_threads_init (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5065687: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 1,596 bytes in 3 blocks are still reachable in loss record 38 of 40
==3835== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==3835== by 0x5ADA598: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD8E68: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD8EBB: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD8F28: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AB9BBA: dbus_parse_address (in /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2ADE: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x50653B2: libvlc_InternalInit (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x4E33807: libvlc_new (in /usr/lib/libvlc.so.2.1.0)
==3835== by 0x400FA2: (within /usr/bin/vlc)
==3835== by 0x554E5A5: (below main) (in /lib/libc-2.9.so)
==3835==
==3835==
==3835== 4,128 bytes in 2 blocks are definitely lost in loss record 39 of 40
==3835== at 0x4C279E1: realloc (vg_replace_malloc.c:429)
==3835== by 0x5ADAEBB: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ADE3E7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ADE7C0: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD511A: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0xC1D808A: ???
==3835== by 0x50C5F34: __module_Need (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x506ED8E: __intf_Create (in /usr/lib/libvlccore.so.0.1.0)
==3835== by 0x506327F: libvlc_InternalAddIntf (in /usr/lib/libvlccore.so.0.1.0)
==3835==
==3835==
==3835== 5,581 bytes in 12 blocks are still reachable in loss record 40 of 40
==3835== at 0x4C279E1: realloc (vg_replace_malloc.c:429)
==3835== by 0x5ADAEBB: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ADB946: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABC194: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABC249: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5444: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD5562: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD6739: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD68E9: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AD4FC6: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5AC2B2E: (within /lib/libdbus-1.so.3.4.0)
==3835== by 0x5ABDCE7: (within /lib/libdbus-1.so.3.4.0)
==3835==
==3835== LEAK SUMMARY:
==3835== definitely lost: 6,052 bytes in 47 blocks.
==3835== indirectly lost: 742 bytes in 18 blocks.
==3835== possibly lost: 0 bytes in 0 blocks.
==3835== still reachable: 11,828 bytes in 86 blocks.
==3835== suppressed: 0 bytes in 0 blocks.
----------------------------------------------------------

I really hope that with this information, a solution, once and for all, can be found.
If more testing or logging is required, please let me know and I am ready here to do whatever it takes to help resolve this memory leak issue.

Regards,
CrazyBuntu

[CrazyBuntu]

bump...

[Rémi Denis-Courmont]

According to your report, of 169 gigabyte of memory processed, VLC has leaked 18 kilobytes mostly through DBus (and a little through libxml and libc)... Needless to say, this is utterly unhelpful in tracking the DVB problem.

As far as I am concerned, this remains unidentified and unreproducible and hence unfixable.

[CrazyBuntu]

Remi,

Thanks for the reply.
I cannot understand how you can say "unreproducible" when I have tried to stream this on 5 different servers/PCs and all have exactly the same problem, over the past 12 months.
And, not only I am having this problem, countless people have exactly the same issue!
Here is another thread that ended up being unanswered for such a long time: viewtopic.php?f=4&t=45215&p=152799&hili ... pt#p152799
and here: viewtopic.php?f=13&t=42574&p=133219&hil ... pt#p133219 and here viewtopic.php?f=4&t=8481&p=26033&hilit= ... ipt#p26033

I have 4GB of RAM in the server and the ram is totally consumed with using 2 instances of VLC, within 24 hours!!!
If I don't run any instances of VLC, there is no memory leak ! Now lets say that I am running VLC for 20 hours. I will have used about 90% of the memory. All I do is stop the VLC process and the memory is mostly returned. Then I start the VLC process again and then the countdown begins again. I do the same thing with VLS, but VLS never leaks memory and is extremely stable. I can, and anyone else can if they try, and this problem will be reproduced at any time, all you need to do to reproduce this is try it yourself. I've given the commands above, just change it to cater for your receive end parameters and you will see for yourself.

Whereas on the same server/pc, I use VLS, I NEVER have this problem, VLS is rock solid and runs smooth as a baby's bum! and I use exactly the same hardware with exactly the same OS and I never get leakage, never have to restart VLS or the server, ever. There are countless persons who have posted this same problem on this forum for Years! But its never been rectified. I've even tried using another program called mumudvb and it runs smooth as VLS with no memory leak and very stable, but problem is that it doesn't have the features like VLC does which is why I am trying to help fix this memory leak problem. VLC is absolutely fantastic software but this memleak problem is its only downfall.

I will make some more tests and I will open a bug report. I wish I knew as much as you guys, and I would fix the damn memleak myself, seeing it seems no one is interested.
However, if you think that this report is not useful, then please help me to help you by advising me on the next step to do in finding the memleak. I followed JB's advise by performing Valgrind check on this. Maybe I have used wrong parameters in valgrind string?

Please advise so that this problem disappears forever.

[Rémi Denis-Courmont]

It's unreproducible because I cannot reproduce it. Not everybody has the same hardware and TV channels as you do...

Strictly speaking, there seems to be no "memory leak", according to valgrind. It looks more like some unbounded buffer is increasing in size until it is destroyed when VLC exits. I do not know any easy way to track that sort of things down.

[CrazyBuntu]

Ok, it has nothing to do with the channels that is being received!!!

In order to reproduce this, you need to do the following:
First
Install either DVB-S or DVB-T card in your PC/Server. Doesn't matter what brand, can be any. I have tested, until now, 6 different brands ranging from Technisat, DVICO, TBS, HAUPPAUGE etc... Thus, the problem is not with the hardware.

Second
Install/Compile VLC 0.9.9a or b and then execute the command as shown above in my example.

Finally
You need to let it run for at least 5 days. You will not see any memory leak after 1 day, unless you use Valgrind.
Unfortunately the amount of memory that Valgrind uses makes it impossible to perform this test for more than 20 hours using 4GB of RAM.
Even if you insert 16GB of ram in the PC, you will only get 3 to 4 days max.

However if you execute the command provided above, without valgrind, you will see that within 5 days you will have no memory left.
If there is a way to find out where the memory leak came from with some other command or program, please advise me and I will do it!

The thing is that if I use VLS, I NEVER get this problem! If I use mumudvb I NEVER get this problem. I can run the servers for months, without rebooting them, and they work flawlessly. I have a server running VLS for the last 1.8 years, Never been rebooted once and VLS is running rock solid without any failure!
This is running exactly the same hardware that I used in the other servers I have been testing. I've even run a test on the server that is having this problem and because I am using VLS, I Never have a memory leak. I have run the server for 2 weeks without fail using VLS.
I then install VLC 0.9.9a and then execute the command using same channels and same hardware and within 5 days, the server will freeze because it has consumed all RAM and also all swap memory. That is how I know that what I have written is factual, not fiction!

Please try this yourself, but you need to run minimum 10 channels for at least 5 days using 1GB ram, you will see that you can reproduce this problem very easily.

If you do not wish to do this, please tell me what else you want me to test this with/how and I will do it for you and post the output here on the forum with the hope that someone can recognise where the problem is and fix it.

[horsedorf]

Hello there folks,

I hate to jump in so late here, but I've been running vlc in anticipation of using it to stream video from an embedded system and so I'm running tests on vlc to determine what kind of processor it would take. TO make an insanely long story short, I'm noticing what appears to be a similiar problem to what you are seeing, CrazyBuntu. However, I am able to reproduce this without any special hardware.

I have not yet run valgrind on this to see if it is truly a memory leak or not, but it does appear to be one.

What I've done so far to reproduce this error is
1) I pulled a video from youtube, an swf file then used ffmpeg to turn it into an mpg file. (Mpeg2)
2) I then have run vlc with the following command line.
vlc -vvv NineShaneAcker.flv.mpg --repeat --sout='#transcode{vcodec=h264}':'rtp{dst=192.168.2.54,port=1238,sdp=rtsp://192.168.2.34:8088/test.sdp}'
3) I then have been following it's memory useage with
top -p (the pid of the vlc process) -d 1
which gives me (I copied the data lines)
pid user PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9867 rickd 20 0 24328 9004 3080 S 40.5 0.4 0:12.17 vlc
9867 rickd 20 0 25740 10m 3080 S 48.5 0.5 1:26.08 vlc

The longer this runs, the more the resident memory set increases in size until eventually it's above 24meg and virtual memory is sitting at over 45meg.

So this seems to be a good way to reproduce this, though I have no idea at this time if it is the SAME leak or not, or even if it IS a leak, though it certainly feels like one.

So what would folks like me to do next to find out what's going on here? Though I'm hoping I've given enough information to be able to reproduce this so that folks with more experience with both valgrind and the debugging toolset can maybe now find what is going on in the code or if it even IS a vlc code problem.

PS. *edit* I built this myself using ./configure --enable-optimize-memory --disable-dvdnav --disable-cdda --disable-libcddb --disable-x11 --disable-xvideo --disable-glx --disable-opengl --disable-sdl --disable-skins2 --enable-x264
which would explain why the memory footprint starts out so tiny.

Rick

[Jean-Baptiste Kempf]

Can you remove the --enable-optimize-memory and try again?
Can you provide a full valgrind log and post it here or send it to me by mail?

[horsedorf]

Can you remove the --enable-optimize-memory and try again?
Can you provide a full valgrind log and post it here or send it to me by mail?

Yes, I can remove teh enable optimize memory flag and rebuild and try again, however, I think it will just verify that the problem is still there as I have observed this behaviour prior to rebuilding with enable optimize memory.
Also, I just took a look at it this morning and two interesting things have happened, one, the top is showing the process to now be using 117meg of memory. On the receive side, I'm using vlc to watch the stream and it had to close with the message "Too many RTP streams".
Also, I have two vlc servers running, one that is doing a transcode, one that is not, the one doing the transcode is the one tha thas gotten huge, the one that is not doign the transcode start at 4532k resident memory and now is showing 4736k of resident memory after running all night. The transcoded stream had a vlc client watching it using "udp" and just looking at socket 8080.

Now, as for running valgrind, I have little experience using it, could you tell me what flags I should use with it to get information you might need on it?
Thanks!
Rick

[Rémi Denis-Courmont]

VLC only follows one RTP stream by default. You can increase the limit, but you will get two videos at the same time... Normally, you'd rather want to not send two streams to the same destination...

[horsedorf]

I started up valgrind using the following...

valgrind -v --leak-check=full --log-file=tc-vlc-valgrind.log vlc -vvv NineShaneAcker.flv.mpg --repeat --sout='#transcode{vcodec=h264}':'rtp{dst=192.168.2.54,port=1238,sdp=rtsp://192.168.2.34:8088/test.sdp}'

and I did so on a version of vlc that I built using the following config.

./configure --disable-dvdnav --disable-cdda --disable-libcddb --disable-x11 --disable-xvideo --disable-glx --disable-opengl --disable-sdl --disable-skins2 --enable-x264

The problem I'm having with this now is that I get a constant stream of "late picture skipped" errors now, apparently my laptop does not have the testicle fortitude to run valgrind on vlc without consuming too much of the laptop's resources (cpu throughput, namely). Is this a 'normal' result of running valgrind on a process?

running it without valgrind shows me what I was expecting, a slow gradual increas of resident memory being used over time, only starting with a larger memory set due to it having been built without memory optimization.

Has anyone else been able to reproduce this with their own systems? Hopefully someone can since what I'm doing does not require any specialized hardware. Just an flv file, that's been converted to mpg with ffmpeg and two computers. And then serving the stream from a linux box to the other machine that's viewing the stream. Hopefully you can see what I am seeing. More eyes on this would be a good thing. In the mean time, I'll do what I can to try and further isolate where/when and how this is happening.

Rick

[horsedorf]

VLC only follows one RTP stream by default. You can increase the limit, but you will get two videos at the same time... Normally, you'd rather want to not send two streams to the same destination...

Yes, I had gathered that, and when running this "for real" I'll be doing that, however, I wanted to see memory useage for the two different processes with one running the transcoding to mpeg4 part10 and the other not doing any transcoding at all.

It ran fine for quite a while, I let it run over night and when I got back to it in the morning, the receive side was complaining to too many rtp streams. I was wondering if the invocation I used caused it to start generating a new stream each time which caused problems somehow? At any rate, i think it might be a different issue other than the memory useage issue I'm seeing. But of course, until it's dug into further I can't really be certain of that. As I move forward though, I'll not be running two instances of vlc and instead just run one instance of it.

Rick

[Rémi Denis-Courmont]

valgrind is very CPU intensive, yes. I never managed to decode video under valgrind.

[horsedorf]

valgrind is very CPU intensive, yes. I never managed to decode video under valgrind.

Darn, that's inconvenient! It's going to be hard to find a memory leak, then, if the tool that lets us find it takes up most of the cpu's time. Perhaps what is needed here is someone who has a latest greatest up to datest cpu running linux who can possibly try running these experiments to see if the problem is reproducible on their machine, and then, if so, run valgrind against vlc and hopefully have enough processing power to be able to do that as well as encode the mpeg4part10 video stream with vlc so that it can find the memory leak?

Sadly, I do not have that kind of computing power myself. My laptop is running an old celeron 1.4ghz processor and it simply does not have the raw throughput to run valgrind and vlc and be able to repproduce this.. though I'll try again with just sending out the mpg file since I do notice that it tends to slowly creep in memory size as well. I'll set it up friday evening and let it run over the weekend to see if it can produce some results to look at.

Any and all input is appreciated.

Rick

[sanitariu]

Rémi Denis-Courmont if you like i can give you root access to one of these DVB-S streaming arround 10 channels.
I tried latest git and it still leaks.
Server can not work more than 15-20 hours. After start swapping vlc streams are dead and need restart.
Contact me if you like access.

[Rémi Denis-Courmont]

DVB is quite outside my area of expertise. I doubt I can help.

[krakorar]

Hello,

I believe that I have found this memory leak in vlc-0.9.10. I am using a Creative Optia AF USB web cam and a PCM microphone. If the PCM microphone is not plugged then I see vlc consume memory until the Linux OOM killer makes an appearance some 20 or so odd minutes later. The problem is that video is buffered by the MPEG4 video encoder and stuffed into a FIFO to be consumed by the MPEG2 transport packetizer as does the MP3 audio encoder. However, the MPEG2 transport packetizer (the Mux function in ts.c) performs a short-circuit return if either of the aforementioned video or audio FIFOs contain less than one packet. In my case the audio FIFO did not contain any packets causing the Mux function in ts.c to perform a short circuit return before the video FIFO could be emptied on the next iteration of the loop. The video FIFO would then fill until I killed vlc, until the Linux OOM killer intervened or until the PCM microphone was plugged into the PCM audio input. Here is my command line:

/usr/bin/vlc -I dummy -V dummy -vvvvv --dscp=0x01 v4l2:// :v4l2-dev=/dev/video0 :v4l2-adev="hw.0,0" :v4l2-width=720 :v4l2-height=480 :v4l2-standard=0 --sout '#transcode{vcodec=mp4v,vb=6000,fps=30,scale=1,acodec=mpga,ab=128,channels=2}:duplicate{dst=rtp{mux=ts,sdp=rtsp://192.168.1.160:16200/camera.sdp}}' vlc://quit

Here is the modified Mux function in ts.c...I am sure someone could find a more elegant solution...

Code: Select all

/***************************************************************************** * Mux: Call each time there is new data for at least one stream ***************************************************************************** * *****************************************************************************/ static int Mux( sout_mux_t *p_mux ) { sout_mux_sys_t *p_sys = p_mux->p_sys; ts_stream_t *p_pcr_stream; if( p_sys->i_pcr_pid == 0x1fff ) { int i; for( i = 0; i < p_mux->i_nb_inputs; i++ ) { block_FifoEmpty( p_mux->pp_inputs[i]->p_fifo ); } msg_Dbg( p_mux, "waiting for PCR streams" ); msleep( 1000 ); return VLC_SUCCESS; } p_pcr_stream = (ts_stream_t*)p_sys->p_pcr_input->p_sys; for( ;; ) { sout_buffer_chain_t chain_ts; int i_packet_count; int i_packet_pos; mtime_t i_pcr_dts; mtime_t i_pcr_length; mtime_t i_shaping_delay; int i, j; if( p_pcr_stream->b_key_frame ) { i_shaping_delay = p_pcr_stream->i_pes_length; } else { i_shaping_delay = p_sys->i_shaping_delay; } /* 1: get enough PES packet for all input */ for( ;; ) { bool b_ok = true; block_t *p_data; /* Accumulate enough data in the pcr stream (>i_shaping_delay) */ /* Accumulate enough data in all other stream ( >= length of pcr)*/ for( i = -1; i < p_mux->i_nb_inputs; i++ ) { sout_input_t *p_input; ts_stream_t *p_stream; int64_t i_spu_delay = 0; if( i == -1 ) p_input = p_sys->p_pcr_input; else if( p_mux->pp_inputs[i]->p_sys == p_pcr_stream ) continue; else p_input = p_mux->pp_inputs[i]; p_stream = (ts_stream_t*)p_input->p_sys; if( ( ( p_stream == p_pcr_stream ) && ( p_stream->i_pes_length < i_shaping_delay ) ) || ( p_stream->i_pes_dts + p_stream->i_pes_length < p_pcr_stream->i_pes_dts + p_pcr_stream->i_pes_length ) ) { for( j = 0; j < p_mux->i_nb_inputs; j++ ) { if ( ( ( p_mux->pp_inputs[j]->p_fmt->i_cat == AUDIO_ES ) || ( p_mux->pp_inputs[j]->p_fmt->i_cat == VIDEO_ES ) ) && block_FifoCount( p_mux->pp_inputs[j]->p_fifo ) > 1) { break; } } if ( j == p_mux->i_nb_inputs ) { /* We need more data */ return VLC_SUCCESS; } /* Need more data */ if( block_FifoCount( p_input->p_fifo ) <= 1 ) { if( !(( p_input->p_fmt->i_cat == AUDIO_ES ) || ( p_input->p_fmt->i_cat == VIDEO_ES )) && (block_FifoCount( p_input->p_fifo ) <= 0)) { /* spu, only one packet is needed */ continue; } else if( p_input->p_fmt->i_cat == SPU_ES ) { /* Don't mux the SPU yet if it is too early */ block_t *p_spu = block_FifoShow( p_input->p_fifo ); i_spu_delay = p_spu->i_dts - p_pcr_stream->i_pes_dts; if( ( i_spu_delay > i_shaping_delay ) && ( i_spu_delay < INT64_C(100000000) ) ) continue; if ( ( i_spu_delay >= INT64_C(100000000) ) || ( i_spu_delay < INT64_C(10000) ) ) { BufferChainClean( &p_stream->chain_pes ); p_stream->i_pes_dts = 0; p_stream->i_pes_used = 0; p_stream->i_pes_length = 0; continue; } } } b_ok = false; if( p_stream == p_pcr_stream || p_sys->b_data_alignment || p_input->p_fmt->i_codec != VLC_FOURCC('m', 'p', 'g', 'a') ) { p_data = NULL; if ( ( block_FifoCount( p_input->p_fifo ) > 0 ) || ( p_input->p_fmt->i_cat == SPU_ES) ) { p_data = block_FifoGet( p_input->p_fifo ); } if( p_input->p_fmt->i_codec == VLC_FOURCC('m', 'p', '4', 'a' ) ) p_data = Add_ADTS( p_data, p_input->p_fmt ); } else p_data = FixPES( p_mux, p_input->p_fifo ); if (p_data) { if( block_FifoCount( p_input->p_fifo ) > 0 && p_input->p_fmt->i_cat != SPU_ES ) { block_t *p_next = block_FifoShow( p_input->p_fifo ); p_data->i_length = p_next->i_dts - p_data->i_dts; } else if( p_input->p_fmt->i_codec != VLC_FOURCC('s', 'u', 'b', 't' ) ) p_data->i_length = 1000; if( ( p_pcr_stream->i_pes_dts > 0 && p_data->i_dts - 10000000 > p_pcr_stream->i_pes_dts + p_pcr_stream->i_pes_length ) || p_data->i_dts < p_stream->i_pes_dts || ( p_stream->i_pes_dts > 0 && p_input->p_fmt->i_cat != SPU_ES && p_data->i_dts - 10000000 > p_stream->i_pes_dts + p_stream->i_pes_length ) ) { msg_Warn( p_mux, "packet with too strange dts " "(dts=%"PRId64",old=%"PRId64",pcr=%"PRId64")", p_data->i_dts, p_stream->i_pes_dts, p_pcr_stream->i_pes_dts ); block_Release( p_data ); BufferChainClean( &p_stream->chain_pes ); p_stream->i_pes_dts = 0; p_stream->i_pes_used = 0; p_stream->i_pes_length = 0; if( p_input->p_fmt->i_cat != SPU_ES ) { BufferChainClean( &p_pcr_stream->chain_pes ); p_pcr_stream->i_pes_dts = 0; p_pcr_stream->i_pes_used = 0; p_pcr_stream->i_pes_length = 0; } } else { int i_header_size = 0; int b_data_alignment = 0; if( p_input->p_fmt->i_cat == SPU_ES ) { if( p_input->p_fmt->i_codec == VLC_FOURCC('s','u','b','t') ) { /* Prepend header */ p_data = block_Realloc( p_data, 2, p_data->i_buffer ); p_data->p_buffer[0] = ( (p_data->i_buffer - 2) >> 8) & 0xff; p_data->p_buffer[1] = ( (p_data->i_buffer - 2) ) & 0xff; /* remove trailling \0 if any */ if( p_data->i_buffer > 2 && p_data->p_buffer[p_data->i_buffer -1] == '\0' ) p_data->i_buffer--; /* Append a empty sub (sub text only) */ if( p_data->i_length > 0 && !( p_data->i_buffer == 1 && *p_data->p_buffer == ' ' ) ) { block_t *p_spu = block_New( p_mux, 3 ); p_spu->i_dts = p_spu->i_pts = p_data->i_dts + p_data->i_length; p_spu->i_length = 1000; p_spu->p_buffer[0] = 0; p_spu->p_buffer[1] = 1; p_spu->p_buffer[2] = ' '; EStoPES( p_mux->p_sout, &p_spu, p_spu, p_input->p_fmt, p_stream->i_stream_id, 1, 0, 0, 0 ); p_data->p_next = p_spu; } } else if( p_input->p_fmt->i_codec == VLC_FOURCC('t','e','l','x') ) { /* EN 300 472 */ i_header_size = 0x24; b_data_alignment = 1; } else if( p_input->p_fmt->i_codec == VLC_FOURCC('d','v','b','s') ) { /* EN 300 743 */ b_data_alignment = 1; } } else if( p_data->i_length < 0 || p_data->i_length > 2000000 ) { /* FIXME choose a better value, but anyway we * should never have to do that */ p_data->i_length = 1000; } p_stream->i_pes_length += p_data->i_length; if( p_stream->i_pes_dts == 0 ) { p_stream->i_pes_dts = p_data->i_dts; } /* Convert to pes */ if( p_stream->i_stream_id == 0xa0 && p_data->i_pts <= 0 ) { /* XXX yes I know, it's awful, but it's needed, * so don't remove it ... */ p_data->i_pts = p_data->i_dts; } EStoPES ( p_mux->p_sout, &p_data, p_data, p_input->p_fmt, p_stream->i_stream_id, 1, b_data_alignment, i_header_size, 0 ); BufferChainAppend( &p_stream->chain_pes, p_data ); if( p_sys->b_use_key_frames && p_stream == p_pcr_stream && (p_data->i_flags & BLOCK_FLAG_TYPE_I) && !(p_data->i_flags & BLOCK_FLAG_NO_KEYFRAME) && (p_stream->i_pes_length > 400000) ) { i_shaping_delay = p_stream->i_pes_length; p_stream->b_key_frame = 1; } } } } } for( j = 0; j < p_mux->i_nb_inputs; j++ ) { if ( ( ( p_mux->pp_inputs[j]->p_fmt->i_cat == AUDIO_ES ) || ( p_mux->pp_inputs[j]->p_fmt->i_cat == VIDEO_ES ) ) && block_FifoCount( p_mux->pp_inputs[j]->p_fifo ) <= 1) { /* We need more data */ return VLC_SUCCESS; } } if( b_ok ) { break; } } /* save */ i_pcr_dts = p_pcr_stream->i_pes_dts; i_pcr_length = p_pcr_stream->i_pes_length; p_pcr_stream->b_key_frame = 0; /* msg_Dbg( p_mux, "starting muxing %lldms", i_pcr_length / 1000 ); */ /* 2: calculate non accurate total size of muxed ts */ i_packet_count = 0; for( i = 0; i < p_mux->i_nb_inputs; i++ ) { ts_stream_t *p_stream = (ts_stream_t*)p_mux->pp_inputs[i]->p_sys; block_t *p_pes; /* False for pcr stream but it will be enough to do PCR algo */ for( p_pes = p_stream->chain_pes.p_first; p_pes != NULL; p_pes = p_pes->p_next ) { int i_size = p_pes->i_buffer; if( p_pes->i_dts + p_pes->i_length > p_pcr_stream->i_pes_dts + p_pcr_stream->i_pes_length ) { mtime_t i_frag = p_pcr_stream->i_pes_dts + p_pcr_stream->i_pes_length - p_pes->i_dts; if( i_frag < 0 ) { /* Next stream */ break; } i_size = p_pes->i_buffer * i_frag / p_pes->i_length; } i_packet_count += ( i_size + 183 ) / 184; } } /* add overhead for PCR (not really exact) */ i_packet_count += (8 * i_pcr_length / p_sys->i_pcr_delay + 175) / 176; /* 3: mux PES into TS */ BufferChainInit( &chain_ts ); /* append PAT/PMT -> FIXME with big pcr delay it won't have enough pat/pmt */ GetPAT( p_mux, &chain_ts ); GetPMT( p_mux, &chain_ts ); i_packet_pos = 0; i_packet_count += chain_ts.i_depth; /* msg_Dbg( p_mux, "estimated pck=%d", i_packet_count ); */ for( ;; ) { int i_stream; mtime_t i_dts; ts_stream_t *p_stream; sout_input_t *p_input; block_t *p_ts; bool b_pcr; /* Select stream (lowest dts) */ for( i = 0, i_stream = -1, i_dts = 0; i < p_mux->i_nb_inputs; i++ ) { p_stream = (ts_stream_t*)p_mux->pp_inputs[i]->p_sys; if( p_stream->i_pes_dts == 0 ) { continue; } if( i_stream == -1 || p_stream->i_pes_dts < i_dts ) { i_stream = i; i_dts = p_stream->i_pes_dts; } } if( i_stream == -1 || i_dts > i_pcr_dts + i_pcr_length ) { break; } p_stream = (ts_stream_t*)p_mux->pp_inputs[i_stream]->p_sys; p_input = p_mux->pp_inputs[i_stream]; /* do we need to issue pcr */ b_pcr = false; if( p_stream == p_pcr_stream && i_pcr_dts + i_packet_pos * i_pcr_length / i_packet_count >= p_sys->i_pcr + p_sys->i_pcr_delay ) { b_pcr = true; p_sys->i_pcr = i_pcr_dts + i_packet_pos * i_pcr_length / i_packet_count; } /* Build the TS packet */ p_ts = TSNew( p_mux, p_stream, b_pcr ); if( p_sys->csa != NULL && (p_input->p_fmt->i_cat != AUDIO_ES || p_sys->b_crypt_audio) && (p_input->p_fmt->i_cat != VIDEO_ES || p_sys->b_crypt_video) ) { p_ts->i_flags |= BLOCK_FLAG_SCRAMBLED; } i_packet_pos++; /* */ BufferChainAppend( &chain_ts, p_ts ); } /* 4: date and send */ TSSchedule( p_mux, &chain_ts, i_pcr_length, i_pcr_dts ); } }

Best Regards,

Rob Krakora

[ILEoo]

please send unified diff against git master about that change to vlc-devel if you think it fixes your problem