App using gstwaylandsink leaks fds
Locked
App using gstwaylandsink leaks fds
 
|
Hello all,
I have a minimal app using gstwaylandsink to show video from IP cameras. I found that every time the pipeline is stopped and destroyed, fds are leaked. After some time the application cannot create any fds and fails with a trace similar to this: ERROR> 0:41:16.094958597 584 0xb3ef5b20 ERROR waylandsink wlshmallocator.c:59:gst_wl_shm_allocator_alloc:<wlshmallocator0> opening temp file /run/xdg/wayland-shm-1644-51WWXP failed: Too many open files ERROR> 0:41:16.095183222 584 0xb3ef5b20 WARN GST_BUFFER gstbuffer.c:907:gst_buffer_new_allocate: failed to allocate 4 bytes ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_memset: assertion 'GST_IS_BUFFER (buffer)' failed ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_peek_memory: assertion 'GST_IS_BUFFER (buffer)' failed ERROR> ** (gstplayer:584): CRITICAL **: gst_fd_memory_get_fd: assertion 'mem != NULL' failed ERROR> 0:41:16.095766306 584 0xb3ef5b20 ERROR waylandsink wlshmallocator.c:211:gst_wl_shm_memory_construct_wl_buffer:<GstWlDisplay@0xb3e55210> wl_shm_memory: dup failed for fd=-1 (err=-1) mem=(nil) From a quick look at the source code I see that the fds are being allocated in gst_wl_shm_allocator_alloc [1]. But where are they being (/should they be) released? I need to dig further into this, but I'm not familiar with how this works -- any hints would be welcome. [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/wayland/wlshmallocator.c#L40 -- Guillermo Rodriguez Garcia [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: App using gstwaylandsink leaks fds
|
|
Le mercredi 25 mars 2020 à 20:28 +0100, Guillermo Rodriguez Garcia a
écrit : > Hello all, > > I have a minimal app using gstwaylandsink to show video from IP > cameras. I found that every time the pipeline is stopped and > destroyed, fds are leaked. After some time the application cannot > create any fds and fails with a trace similar to this: > > ERROR> 0:41:16.094958597 584 0xb3ef5b20 ERROR waylandsink > wlshmallocator.c:59:gst_wl_shm_allocator_alloc:<wlshmallocator0> > opening temp file /run/xdg/wayland-shm-1644-51WWXP failed: Too many > open files > ERROR> 0:41:16.095183222 584 0xb3ef5b20 WARN GST_BUFFER > gstbuffer.c:907:gst_buffer_new_allocate: failed to allocate 4 bytes > ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_memset: > assertion 'GST_IS_BUFFER (buffer)' failed > ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_peek_memory: > assertion 'GST_IS_BUFFER (buffer)' failed > ERROR> ** (gstplayer:584): CRITICAL **: gst_fd_memory_get_fd: > assertion 'mem != NULL' failed > ERROR> 0:41:16.095766306 584 0xb3ef5b20 ERROR waylandsink > wlshmallocator.c:211:gst_wl_shm_memory_construct_wl_buffer:<GstWlDisplay@0xb3e55210> > wl_shm_memory: dup failed for fd=-1 (err=-1) mem=(nil) > > From a quick look at the source code I see that the fds are being > allocated in gst_wl_shm_allocator_alloc [1]. But where are they being > (/should they be) released? We do 'gst_buffer_replace (&sink->last_buffer, to_render);' which drop reference on last_buffer, and take ownerhsip of to_render. What GStreamer version is this ? Do you have some information on how to reproduce ? I don't face this issue here. > > I need to dig further into this, but I'm not familiar with how this > works -- any hints would be welcome. > > [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/wayland/wlshmallocator.c#L40 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: App using gstwaylandsink leaks fds
|
|
Hi,
El mié., 25 mar. 2020 a las 22:50, Nicolas Dufresne (<[hidden email]>) escribió: > > Le mercredi 25 mars 2020 à 20:28 +0100, Guillermo Rodriguez Garcia a > écrit : > > Hello all, > > > > I have a minimal app using gstwaylandsink to show video from IP > > cameras. I found that every time the pipeline is stopped and > > destroyed, fds are leaked. After some time the application cannot > > create any fds and fails with a trace similar to this: > > > > ERROR> 0:41:16.094958597 584 0xb3ef5b20 ERROR waylandsink > > wlshmallocator.c:59:gst_wl_shm_allocator_alloc:<wlshmallocator0> > > opening temp file /run/xdg/wayland-shm-1644-51WWXP failed: Too many > > open files > > ERROR> 0:41:16.095183222 584 0xb3ef5b20 WARN GST_BUFFER > > gstbuffer.c:907:gst_buffer_new_allocate: failed to allocate 4 bytes > > ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_memset: > > assertion 'GST_IS_BUFFER (buffer)' failed > > ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_peek_memory: > > assertion 'GST_IS_BUFFER (buffer)' failed > > ERROR> ** (gstplayer:584): CRITICAL **: gst_fd_memory_get_fd: > > assertion 'mem != NULL' failed > > ERROR> 0:41:16.095766306 584 0xb3ef5b20 ERROR waylandsink > > wlshmallocator.c:211:gst_wl_shm_memory_construct_wl_buffer:<GstWlDisplay@0xb3e55210> > > wl_shm_memory: dup failed for fd=-1 (err=-1) mem=(nil) > > > > From a quick look at the source code I see that the fds are being > > allocated in gst_wl_shm_allocator_alloc [1]. But where are they being > > (/should they be) released? > > We do 'gst_buffer_replace (&sink->last_buffer, to_render);' which drop > reference on last_buffer, and take ownerhsip of to_render. I see, thank you for the hint! > > What GStreamer version is this ? Do you have some information on how to > reproduce ? I don't face this issue here. I saw this with 1.14.4. I will try to reproduce it with a more recent version, and also will try to come up with a minimal sample reproducing the issue. Best case I will find the problem during the process. Worst case I will have something to post here and ask for further help. Thanks, Guillermo Rodriguez Garcia [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: App using gstwaylandsink leaks fds
|
|
Hi,
El jue., 26 mar. 2020 a las 11:28, Guillermo Rodriguez Garcia (<[hidden email]>) escribió: > > Hi, > > El mié., 25 mar. 2020 a las 22:50, Nicolas Dufresne > (<[hidden email]>) escribió: > > > > Le mercredi 25 mars 2020 à 20:28 +0100, Guillermo Rodriguez Garcia a > > écrit : > > > Hello all, > > > > > > I have a minimal app using gstwaylandsink to show video from IP > > > cameras. I found that every time the pipeline is stopped and > > > destroyed, fds are leaked. After some time the application cannot > > > create any fds and fails with a trace similar to this: > > > > > > ERROR> 0:41:16.094958597 584 0xb3ef5b20 ERROR waylandsink > > > wlshmallocator.c:59:gst_wl_shm_allocator_alloc:<wlshmallocator0> > > > opening temp file /run/xdg/wayland-shm-1644-51WWXP failed: Too many > > > open files > > > ERROR> 0:41:16.095183222 584 0xb3ef5b20 WARN GST_BUFFER > > > gstbuffer.c:907:gst_buffer_new_allocate: failed to allocate 4 bytes > > > ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_memset: > > > assertion 'GST_IS_BUFFER (buffer)' failed > > > ERROR> (gstplayer:584): GStreamer-CRITICAL **: gst_buffer_peek_memory: > > > assertion 'GST_IS_BUFFER (buffer)' failed > > > ERROR> ** (gstplayer:584): CRITICAL **: gst_fd_memory_get_fd: > > > assertion 'mem != NULL' failed > > > ERROR> 0:41:16.095766306 584 0xb3ef5b20 ERROR waylandsink > > > wlshmallocator.c:211:gst_wl_shm_memory_construct_wl_buffer:<GstWlDisplay@0xb3e55210> > > > wl_shm_memory: dup failed for fd=-1 (err=-1) mem=(nil) > > > > > > From a quick look at the source code I see that the fds are being > > > allocated in gst_wl_shm_allocator_alloc [1]. But where are they being > > > (/should they be) released? > > > > We do 'gst_buffer_replace (&sink->last_buffer, to_render);' which drop > > reference on last_buffer, and take ownerhsip of to_render. > > I see, thank you for the hint! > > > > > What GStreamer version is this ? Do you have some information on how to > > reproduce ? I don't face this issue here. > > I saw this with 1.14.4. I will try to reproduce it with a more recent > version, and also will try to come up with a minimal sample > reproducing the issue. > Best case I will find the problem during the process. Worst case I > will have something to post here and ask for further help. Ok, I found something. The problem is not directly related to waylandsink. Every time I create a pipeline I am attaching a bus watch as follows: GstBus *bus = gst_pipeline_get_bus(GST_PIPELINE(pipeline)); gst_bus_add_watch(bus, bus_error_handler, NULL); gst_object_unref(bus); Later when I'm done with the pipeline it is destroyed as follows: gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_NULL); gst_object_unref(GST_OBJECT(pipeline)); I understood that I didn't need to explicitly remove the bus watch when destroying the pipeline, from this earlier reply from Sebastian Dröge: https://lists.freedesktop.org/archives/gstreamer-devel/2015-August/054038.html However this results in fd leaks as described. If I explicitly remove the bus watch when the pipeline is destroyed: g_source_remove (bus_watch_id); then the leaks are gone. Does this make sense? Guillermo Rodriguez Garcia [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: App using gstwaylandsink leaks fds
|
|
Le jeudi 26 mars 2020 à 13:38 +0100, Guillermo Rodriguez Garcia a
écrit : > However this results in fd leaks as described. > If I explicitly remove the bus watch when the pipeline is destroyed: > > g_source_remove (bus_watch_id); > > then the leaks are gone. > > Does this make sense? The waylandsink is likely attached as a src of a GstMessage that is stored in the bus. And then the bus or the pipeline is leaked, causing waylandsink internal pool to be leaked, hence the "leaked" fds. Use GST_DEBUG="GST_TRACER:7" GST_TRACERS=leak ... to get a list of leaked objects. Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: App using gstwaylandsink leaks fds
|
|
Hello,
El jue., 26 mar. 2020 a las 15:20, Nicolas Dufresne (<[hidden email]>) escribió: > > Le jeudi 26 mars 2020 à 13:38 +0100, Guillermo Rodriguez Garcia a > écrit : > > However this results in fd leaks as described. > > If I explicitly remove the bus watch when the pipeline is destroyed: > > > > g_source_remove (bus_watch_id); > > > > then the leaks are gone. > > > > Does this make sense? > > The waylandsink is likely attached as a src of a GstMessage that is > stored in the bus. And then the bus or the pipeline is leaked, causing > waylandsink internal pool to be leaked, hence the "leaked" fds. Use > GST_DEBUG="GST_TRACER:7" GST_TRACERS=leak ... to get a list of leaked > objects. Will do. However I'm still in doubt: Am I expected to explicitly remove the bus watch when I destroy the pipeline? Or should this happen automatically? Thanks, Guillermo Rodriguez Garcia [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: App using gstwaylandsink leaks fds
|
|
In reply to this post by Nicolas Dufresne-5
El jue., 26 mar. 2020 a las 15:20, Nicolas Dufresne
(<[hidden email]>) escribió: > > Le jeudi 26 mars 2020 à 13:38 +0100, Guillermo Rodriguez Garcia a > écrit : > > However this results in fd leaks as described. > > If I explicitly remove the bus watch when the pipeline is destroyed: > > > > g_source_remove (bus_watch_id); > > > > then the leaks are gone. > > > > Does this make sense? > > The waylandsink is likely attached as a src of a GstMessage that is > stored in the bus. And then the bus or the pipeline is leaked, causing > waylandsink internal pool to be leaked, hence the "leaked" fds. Use > GST_DEBUG="GST_TRACER:7" GST_TRACERS=leak ... to get a list of leaked > objects. This does not seem to detect the problem. The docs say that this only track leaks in gst code; perhaps this leak is happening at the Glib level? Since the leak is fixed if the bus watch is removed using g_source_remove(). Anyway I think the main question (for me) is whether the bus watch needs to be explicitly removed or not. I understood that it was not necessary, but removing it fixes the problem for me. So either my understanding was wrong, or the fact that the leak goes away when I remove the bus watch is just a coincidence and I should debug that further.. Thanks, Guillermo Rodriguez Garcia [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |