[meta-freescale] Gstreamer-imx leak - socket file handle issue ?

[Carlos Rafael Giani]

Hi Joshua,

I have tried to reconstruct the problem, but could not get valgrind to 
work yet (for some reason, it crashes right away). imxipusink and 
imxeglvivsink keep a reference to the last frame around, just like any 
other video sink. The fakesink doesn't. Perhaps there is some bug in the 
shutdown process, but so far, I always saw that the buffers were 
deallocated correctly (otherwise, the associated buffer pools would not 
be finalized, which they are, according to the logs).

I assume this is using the stock GStreamer 1.0 plugins, without any 
bbappends? Also, dora is still using GStreamer 1.0.x , which is no 
longer recommended for gstreamer-imx. Either move to daisy, or add 
meta-gstreamer1.0 to your bblayers.conf.

On 2014-05-13 21:28, Joshua Kurland wrote:
> It appears I am getting leaky file handles when I run valgrind with 
> gstreamer-imx as the decoder plugin.
>
> G_SLICE=always-malloc valgrind --track-fds=yes --leak-check=full 
> gst-launch-1.0 playbin uri=file:///home/root/quickclip.mpg 
> video-sink=imxipusink
> ==1071== FILE DESCRIPTORS: 7 open at exit.
> ==1071== Open AF_UNIX socket 20: <unknown>
> ==1071==    at 0x4B7F2AC: socketpair (syscall-template.S:81)
> ==1071==    by 0x48B7227: gst_poll_new (in 
> /usr/lib/libgstreamer-1.0.so.0.204.0)
> ==1071==
> ==1071== Open AF_UNIX socket 19: <unknown>
> ==1071==    at 0x4B7F2AC: socketpair (syscall-template.S:81)
> ==1071==    by 0x48B7227: gst_poll_new (in 
> /usr/lib/libgstreamer-1.0.so.0.204.0)
> ==1071==
> ==1071== Open AF_UNIX socket 14: <unknown>
> ==1071==    at 0x4B7F2AC: socketpair (syscall-template.S:81)
> ==1071==    by 0x48B7227: gst_poll_new (in 
> /usr/lib/libgstreamer-1.0.so.0.204.0)
> ==1071==
> ==1071== Open AF_UNIX socket 13: <unknown>
> ==1071==    at 0x4B7F2AC: socketpair (syscall-template.S:81)
> ==1071==    by 0x48B7227: gst_poll_new (in 
> /usr/lib/libgstreamer-1.0.so.0.204.0)
> ==1071==
> ==1071== Open file descriptor 2: /dev/pts/1
> ==1071==    <inherited from parent>
> ==1071==
> ==1071== Open file descriptor 1: /dev/pts/1
> ==1071==    <inherited from parent>
> ==1071==
> ==1071== Open file descriptor 0: /dev/pts/1
> ==1071==    <inherited from parent>
>
> I re-ran the same pipeline but replaced the sink with fakesink. 
>  Valgrind did not report any leaky sockets.
>
> G_SLICE=always-malloc valgrind --track-fds=yes --leak-check=full 
> gst-launch-1.0 playbin uri=file:///home/root/quickclip.mpg 
> video-sink=fakesink
> ==1097== FILE DESCRIPTORS: 3 open at exit.
> ==1097== Open file descriptor 2: /dev/pts/1
> ==1097==    <inherited from parent>
> ==1097==
> ==1097== Open file descriptor 1: /dev/pts/1
> ==1097==    <inherited from parent>
> ==1097==
> ==1097== Open file descriptor 0: /dev/pts/1
> ==1097==    <inherited from parent>
>
> Lastly I ran the same pipeline using gstreamer-0.10.  Again the issue 
> was not present.
>
> G_SLICE=always-malloc valgrind --track-fds=yes --leak-check=full 
> gst-launch-0.10 playbin2 uri=file:///home/root/quickclip.mpg 
> video-sink=mfw_v4lsink
> ==1335== FILE DESCRIPTORS: 3 open at exit.
> ==1335== Open file descriptor 2: /dev/pts/1
> ==1335==    <inherited from parent>
> ==1335==
> ==1335== Open file descriptor 1: /dev/pts/1
> ==1335==    <inherited from parent>
> ==1335==
> ==1335== Open file descriptor 0: /dev/pts/1
> ==1335==    <inherited from parent>
>
> I am building using meta-fsl master branch for the Wandboard-Quad, 
> however the issue originated on Dora branch.  For gstreamer-0.10 I 
> bitbake fsl-image-multimedia-full with x11.  I am adding gstreamer-imx 
> support by appending conf/local.conf with
>     gstreamer1.0 \
>     gstreamer1.0-plugins-base-meta \
>     gstreamer1.0-plugins-good-meta \
>     gstreamer1.0-plugins-bad-meta \
>     gstreamer1.0-plugins-ugly-meta \
>     gstreamer1.0-libav \
>     gstreamer1.0-omx \
>     gstreamer1.0-plugins-imx-meta \
>
> Has anybody else seen this bug?  I am not very familiar with the 
> mechanism for opening files or socketpairs in gstreamer or in the vpu. 
>  Can anyone point me in the right direction so I can determine if 
> there is an issue?
>
> I have attached the valgrind logs for the three tests.
>
> Thank you,
> JK
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140513/aaa94311/attachment.html>