Created attachment 614383 [details] out of memory valgrind output Description of problem: Trying to play some videos (xvid in avi) the application eats memory like Garfield lasagne. Version-Release number of selected component (if applicable): kdemultimedia-dragonplayer-4.8.5-1.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. dragon some_known_to_cause_trouble_video.avi Actual results: dragon is able to allocate about 2 GiB of RAM in two minutes and it continues to rise quickly until the system limits Expected results: the memory usage is constant (I'm getting about 1.7 GiB in top's VIRT column and 550 MiB in RES for similar videos which is insane for a simple video player, mplayer takes 513m VIRT and 21m RES for the same video ...) Additional info: I'm attaching some valgrind output if it is of any help ... I can also provide the testing video but it is about 1 GiB in size I report for Fedora instead of upstream as I cannot reproduce the problem on Gentoo so there has to be something distro-specific
Created attachment 614390 [details] valgrind output after leaking about 0.5 GiB possibly lost: 552,173,254 bytes in 15,397,985 blocks ... no comment
Looks like most of it is in either phonon-gstreamer or gstreamer itself, but I'm no expert in reading those valgrind logs. I'll see if I can get some advice... Does this happen for all media played back, or as you seem to imply, only some video files? If only, some, would it be possible to get a copy or sample to try to reproduce or debug?
Oh, and since you compared fedora with gentoo, is your gentoo system also using gstreamer phonon backend (with pulseaudio) or some other configuration?
(In reply to comment #2) > Does this happen for all media played back, or as you seem to imply, only > some video files? only some > If only, some, would it be possible to get a copy or > sample to try to reproduce or debug? yes, I have one such file ready at hand, but it is nearly 1 GiB - a bit big for bugzilla attachment ... (In reply to comment #3) > Oh, and since you compared fedora with gentoo, is your gentoo system also > using gstreamer phonon backend (with pulseaudio) or some other configuration? no, it doesn't use pulseaudio; as for the backend, I think I'm using vlc - how do I find out for sure? I do not see any config options in Dragon itself, and as for phonon, there is ~/.kde4/share/config/phonondevicesrc but it doesn't tell anything about the backend?
systemsettings->multimedia->phonon, backend(tab)
So, if you're using a completely different backend on Gentoo, that's probably the difference. You can only conclude that there's something distro-specific if you're using the exact same setup on both distros.
(In reply to comment #5) > systemsettings->multimedia->phonon, backend(tab) thanks, yes it's VLC (In reply to comment #6) > So, if you're using a completely different backend on Gentoo, that's > probably the difference. You can only conclude that there's something > distro-specific if you're using the exact same setup on both distros. that depends on the point of view ... it's Fedora what forces me to use pulseaudio and defaults to gstreamer :-) if one default choice works worse than another then I really see it as distro bug that it uses bad defaults - in addition to the underlying bug in the component anyways, sorry for inapropriate wording "has to be" - what I've meant is that it is my suspicion and I'd like to consider this, and ask the package maintainer to act as proxy for the possible upstream bug (if that is in gstreamer, well, I don't even know in which way the upstream bugs are tracked - if they have some bugzilla then I don't have an account there ...) /me goes to try phonon-backend-vlc
cool, using vlc it doesn't play at all, the console output is: $ dragon ordinace-v-ruzove-zahrade-2-353-slibem-nezarmoutis.avi [0x25b0968] main services discovery error: no suitable services discovery module Object::connect: No such signal Phonon::VLC::MediaObject::angleChanged(int) in /builddir/build/BUILD/phonon-4.6.0/phonon/mediacontroller.cpp:64 Object::connect: No such signal Phonon::VLC::MediaObject::availableAnglesChanged(int) in /builddir/build/BUILD/phonon-4.6.0/phonon/mediacontroller.cpp:65 Object::connect: No such signal Phonon::VLC::MediaObject::angleChanged(int) in /builddir/build/BUILD/phonon-4.6.0/phonon/mediacontroller.cpp:64 Object::connect: No such signal Phonon::VLC::MediaObject::availableAnglesChanged(int) in /builddir/build/BUILD/phonon-4.6.0/phonon/mediacontroller.cpp:65 QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::begin: Paint device returned engine == 0, type: 2 WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioDataOutput ( no objectName ). QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::begin: Paint device returned engine == 0, type: 2 [0x7f8b88008ec8] main video output error: video output creation failed [0x7f8ba000aea8] main decoder error: failed to create video output QPainter::begin: Paint device returned engine == 0, type: 2 [0x263a648] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 300 ms) [0x263a648] main input error: ES_OUT_RESET_PCR called
GStreamer uses bugzilla.gnome.org.
(In reply to comment #9) > GStreamer uses bugzilla.gnome.org. but the phonon-backend-* packages point to KDE ... Rex, please, could you decide if that is in the backend or in gstreamer itself? - or should I read Kevin's comment as gstreamer being identified as the culprit? I've tried to compile simple gstreamer player from here: https://github.com/felipec/gst-player/ and after running it under valgrind, it doesn't seem to leak memory that much
Created attachment 633907 [details] valgrind output for gstplayer
(In reply to comment #2) > If only, some, would it be possible to get a copy or > sample to try to reproduce or debug? http://www.hajnet.cz/ordinace-v-ruzove-zahrade-2-353-slibem-nezarmoutis.avi
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
just FTR, cleaning the EOL warnings, and ... ==2786== HEAP SUMMARY: ==2786== in use at exit: 7,841,289 bytes in 23,806 blocks ==2786== total heap usage: 4,402,533 allocs, 4,378,727 frees, 1,003,219,833 bytes allocated ==2786== ==2786== LEAK SUMMARY: ==2786== definitely lost: 18,728 bytes in 26 blocks ==2786== indirectly lost: 8,724 bytes in 74 blocks ==2786== possibly lost: 3,927,007 bytes in 10,330 blocks ==2786== still reachable: 3,886,830 bytes in 13,376 blocks ==2786== suppressed: 0 bytes in 0 blocks ==2786== Rerun with --leak-check=full to see details of leaked memory ==2786== ==2786== For counts of detected and suppressed errors, rerun with: -v ==2786== Use --track-origins=yes to see where uninitialised values come from ==2786== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 2) after five minutes under valgrind a lot better but far from ideal :-(
> just FTR, cleaning the EOL warnings The bug is still considered closed. If you want it open, you need to reopen it and set Version to at least 18.
(In reply to Kevin Kofler from comment #16) > > just FTR, cleaning the EOL warnings > > The bug is still considered closed. er, I've meant cleaning my bugzilla queue, not this bug itself > If you want it open, you need to reopen > it and set Version to at least 18. no, I would no longer consider this "insane" :-) p.s. thanks for correcting the component and sorry for that noise, don't know how could that have happened when just adding comment ...