Bug 858713 - dragon: insane memory leak
dragon: insane memory leak
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: phonon-backend-gstreamer (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-19 09:45 EDT by Karel Volný
Modified: 2013-08-29 10:17 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 05:27:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
out of memory valgrind output (132.58 KB, text/plain)
2012-09-19 09:45 EDT, Karel Volný
no flags Details
valgrind output after leaking about 0.5 GiB (2.92 MB, text/plain)
2012-09-19 09:47 EDT, Karel Volný
no flags Details
valgrind output for gstplayer (2.26 MB, text/x-log)
2012-10-26 11:00 EDT, Karel Volný
no flags Details

  None (edit)
Description Karel Volný 2012-09-19 09:45:27 EDT
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
Comment 1 Karel Volný 2012-09-19 09:47:32 EDT
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
Comment 2 Rex Dieter 2012-09-19 10:53:30 EDT
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?
Comment 3 Rex Dieter 2012-09-19 10:54:11 EDT
Oh, and since you compared fedora with gentoo, is your gentoo system also using gstreamer phonon backend (with pulseaudio) or some other configuration?
Comment 4 Karel Volný 2012-10-24 12:39:21 EDT
(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?
Comment 5 Rex Dieter 2012-10-24 13:35:06 EDT
systemsettings->multimedia->phonon, backend(tab)
Comment 6 Kevin Kofler 2012-10-24 18:33:48 EDT
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.
Comment 7 Karel Volný 2012-10-25 06:06:18 EDT
(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
Comment 8 Karel Volný 2012-10-25 06:46:05 EDT
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
Comment 9 Kevin Kofler 2012-10-25 10:41:48 EDT
GStreamer uses bugzilla.gnome.org.
Comment 10 Karel Volný 2012-10-26 10:59:41 EDT
(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
Comment 11 Karel Volný 2012-10-26 11:00:33 EDT
Created attachment 633907 [details]
valgrind output for gstplayer
Comment 12 Karel Volný 2012-10-26 18:31:22 EDT
(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
Comment 13 Fedora End Of Life 2013-07-03 22:48:57 EDT
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.
Comment 14 Fedora End Of Life 2013-08-01 05:28:04 EDT
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.
Comment 15 Karel Volný 2013-08-20 18:38:50 EDT
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 :-(
Comment 16 Kevin Kofler 2013-08-21 14:09:49 EDT
> 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.
Comment 17 Karel Volný 2013-08-29 10:17:21 EDT
(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 ...

Note You need to log in before you can comment on or make changes to this bug.