The VideoLAN Forums

I recently performed a clean install of Ubuntu Karmic 9.10 64bit on a Dell D630 laptop with 2GB of memory. The default repositories have version 1.02 of VLC. I am using the default install and configuration of Pulseaudio. I discovered what appears to be a memory leak VLC that causes the system to go into a sluggish/unusable state quickly. I was playing a .MP3 file when I noticed system performance started to degrade. I managed to get System Monitor to load and it reported VLC using 1.5GB of memory.

Another thing I noticed with VLC is that it will output a very loud static noise using play. This loud static noise occurs most often when skipping around the song.

I see version 1.03 was released and I installed that via the PPA. But it exhibits the same problems.

I don't have any further diagnostic information. It's tough to get details when the system doesn't respond to keystrokes. But I'm willing to help get more details if someone can walk me though a way to figure out what may be wrong.

Thank you,
John

for a start could you make sure you have vlc-plugin-pulse installed.

Then if you still have the huge mem leak, try to run vlc in valgrind for a little while and see if valgrind find where the leak is

pulseaudio plug was already enable.

Attempt #1
valgrind --log-file=log.txt vlc
started leaking bad. I was able to stop VLC once memory useage climbed over a gig

==2778== Memcheck, a memory error detector
==2778== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2778== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==2778== Command: vlc
==2778== Parent PID: 2334
==2778==
==2778==
==2778== HEAP SUMMARY:
==2778== in use at exit: 0 bytes in 0 blocks
==2778== total heap usage: 1,385 allocs, 1,385 frees, 76,018 bytes allocated
==2778==
==2778== All heap blocks were freed -- no leaks are possible
==2778==
==2778== For counts of detected and suppressed errors, rerun with: -v
==2778== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
==2778==
==2778== HEAP SUMMARY:
==2778== in use at exit: 0 bytes in 0 blocks
==2778== total heap usage: 1,385 allocs, 1,385 frees, 76,018 bytes allocated
==2778==
==2778== All heap blocks were freed -- no leaks are possible
==2778==
==2778== For counts of detected and suppressed errors, rerun with: -v
==2778== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--2778-- WARNING: unhandled syscall: 294
--2778-- You may be able to write your own handler.
--2778-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--2778-- Nevertheless we consider this a bug. Please report
--2778-- it at http://valgrind.org/support/bug_reports.html.
==2778== Thread 9:
==2778== Syscall param write(buf) points to uninitialised byte(s)
==2778== at 0x5119AEB: ??? (in /lib/libc-2.10.1.so)
==2778== by 0xDBE9CFE: ??? (in /usr/lib/libICE.so.6.3.0)
==2778== by 0xDBEE58F: _IceWrite (in /usr/lib/libICE.so.6.3.0)
==2778== by 0xDBEE673: IceFlush (in /usr/lib/libICE.so.6.3.0)
==2778== by 0xBA7EBCC: ??? (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xBA8263F: ??? (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xBA95C3D: ??? (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xBA96928: ??? (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xD9DE4EE: _SmcProcessMessage (in /usr/lib/libSM.so.6.0.0)
==2778== by 0xDBF300B: IceProcessMessages (in /usr/lib/libICE.so.6.3.0)
==2778== by 0xBA7F10E: ??? (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xC591DDB: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/libQtCore.so.4.5.2)
==2778== Address 0x886b8cc is 12 bytes inside a block of size 1,024 alloc'd
==2778== at 0x4C24477: calloc (vg_replace_malloc.c:418)
==2778== by 0xDBE6A98: IceOpenConnection (in /usr/lib/libICE.so.6.3.0)
==2778== by 0xD9DA92A: SmcOpenConnection (in /usr/lib/libSM.so.6.0.0)
==2778== by 0xBA85C5D: QSessionManager::QSessionManager(QApplication*, QString&, QString&) (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xBA29436: QApplicationPrivate::initialize() (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xBA2954A: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xBA2A187: QApplication::QApplication(int&, char**, bool, int) (in /usr/lib/libQtGui.so.4.5.2)
==2778== by 0xB4F29CA: ??? (in /usr/lib/vlc/gui/libqt4_plugin.so)
==2778== by 0x53BDA03: start_thread (pthread_create.c:300)
==2778== by 0x51277BC: clone (clone.S:112)
==2778==
==2778==
==2778== HEAP SUMMARY:
==2778== in use at exit: 550,007,725 bytes in 1,587,051 blocks
==2778== total heap usage: 2,560,870 allocs, 973,819 frees, 1,273,402,381 bytes allocated
==2778==
==2778== LEAK SUMMARY:
==2778== definitely lost: 6,747 bytes in 15 blocks
==2778== indirectly lost: 20,304 bytes in 637 blocks
==2778== possibly lost: 152,754,797 bytes in 429,368 blocks
==2778== still reachable: 397,225,877 bytes in 1,157,031 blocks
==2778== suppressed: 0 bytes in 0 blocks
==2778== Rerun with --leak-check=full to see details of leaked memory
==2778==
==2778== For counts of detected and suppressed errors, rerun with: -v
==2778== Use --track-origins=yes to see where uninitialised values come from
==2778== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 377 from

Attempt #2
valgrind --log-file=log2.txt --leak-check=full -v vlc
wasn't able to get it to leak bad - but I did see memory usage grow over time

View log here http://jnwphoto.com/log2.htm

The only thing i noticed are the noises. VLC has been pretty good to me so far but just recently i've been hearing noises everytime i play something.


Regards,
Danna
Ordinateur portable pas cher

Hello,

I have the same problems (memory leak and random static audio) on a Dell Vostro 220 (Ubuntu 9.10 x64).

Any idea how to fix that ?

Your debug symbols don't match the installed VLC, so the log is quite incomplete.

That said, it seems a lot like the leak if coming from your Qt/Gtk style, not from VLC itself.

hey -

I'm running into the same problem. I'm running Ubuntu 9.10 on a system w/ an Intel QuadCore 64bit CPU and 8 gigs of RAM. between 5 and 30 minutes into using VLC, VLC becomes choppy and sluggish, as does everything else on my system. running the top command shows VLC taking upwards of 7 gigs of RAM and the OS is eating into swap space. only way I've found to resolve properly is to kill -9 the process.

don't have a stack trace handy, but if you tell me what you want to see - please be specific, i.e. "cause the mem leak, then do x, then y, then z, and post this file as an attachment to the board" - and I'll do it.

thanks -

Matt

Don't use the buggy Gtk style for Qt4.

I too have VLC running away with memory. After watching a movie, I saw VLC consuming 81% memory (on a 4G machine).

Maybe with larger text people will read:

Do not use the Gtk styles for Qt4.

OK, then color me ignorant, how do I turn it off? I just use whatever came default.

how do I turn it off

Then system -> preferences -> qt 4 settings -> appearance -> gui style drop down
try cleanlooks
There are other benefits of moving off of the default or gtk style that you may notice

It wasn't set to the GTK style it was set to "desktop" which I assume becomes GTK under GNOME.

Even after changing this to Cleanlooks, I still get memory runaways. Almost instantly my machine went from just fine, 35% memory usage to 96% memory usage and almost unresponsive. Killing VLC immediately solves the problem, and frees the memory.

This is not just a leak but a run-away, and it is *not* related to the GTK theme, since that is now off.

This just happened again while watching an otherwise unremarkable 720p video. Totem plays this same file just fine.

VLC gets so aggressive about memory that my machine swaps itself to death and I have to hard reset it. Yes that's a pathological case for Linux, but it's VLC that is running away. At this point, I can't use VLC anymore unless I have a shell opened with 'killall -9 vlc' already typed so I can maybe have a chance of killing VLC before it kills my machine.

VLC under Karmic is *BROKEN*

Yeah this is a VLC bug (and/or Ubuntu packaging). Others Qt apps are not doing this.

VLC under Karmic is *BROKEN*

Works fine for me...

(and nobody has provided a VALID valgrind trace)

I have no idea how to generate a valgrind trace when vlc under valgrind is absolutely hopeless for actually watching a video.

It can not keep up with a simple standard-def video, much less a high def.

Is there some valgrind magic --run-with-acceptable-performance flag I don't know about?

And it happened again. This is STUPID.

And twice more tonight.

Once more for good measure. Sigh.

I have the same problem.
Memory leak happens very often if I pause the film for some time, then it needs time to consume my 4Gb of memory, but when it happens it takes me quite a lot of time to kill the vlc process which takes all the memory.
As for loud static, most movies don't have such problems, but someone do, it's usually aac codec coded by avidemux 2.51 (it works fine with other players on Ubuntu 9.10).

I have no idea how to generate a valgrind trace when vlc under valgrind is absolutely hopeless for actually watching a video.

I am afraid this is impossible with contemporary technology. valgrind needs to emulate the instruction set.

I have the same problem.

Me-toos really aren't helping track the problem down.

We need either a patch or a reproducible test case.

I'm just looking for clues on how to figure out the repro case. I don't suppose VLC has a verbose instrumentation commandline flag which would help determine the problem when it does happen. It follows no real pattern that I have seen, so it must be timing related or something non-deterministic.

I don't want to be a "me too" guy, but I have the same issue. We finally watched it happen using "top"
--VLC started and operating normally, using about 2.8% of 2GB of memory
--After about 5 minutes, it grew to 3.8%--still operating normally.
--After about 20 minutes of watching a movie, the memory usage grew to 86.7%, seizing up the computer and preventing any other processes from running.

I suspect a memory leak of some kind, especially with the exponential-like use of memory (slow to start, then climbing dramatically.) It may just be a small line of code somewhere that gets used frequently.

I'm perfectly willing to investigate further--i can try compiling from source and using valgrind, if you would like.

The machine I'm using is 2GB RAM, 3 GHZ Intel process, loaded with Fedora Core 12.

By the way, as far as reproducible, we've been able to make it happen 5 out of 5 times...same progression every time.