GNOME Bugzilla – Bug 789547
playbin: Leaking sinks during autoplugging
Last modified: 2017-11-07 14:49:20 UTC
Based on GStreamer app on android, there is a serious problem that fd will leak. Steps to reproduce: ---- We can quickly get an app with the following link: https://cgit.freedesktop.org/gstreamer/gst-examples/tree/playback/player/android Using gst app play a local mp4 file, and then press< return> to exit, use lsof count fds(perhaps you must have root privileges), shell@android# ps|grep org.freedesktop.gstreamer.play u0_a50 7057 1096 883832 68736 ffffffff f765fc34 S org.freedesktop.gstreamer.play shell@android# lsof |grep 7057 ---------- org.freed 7057 u0_a50 27 ??? ??? ??? ??? /data/app/org.freedesktop.gstreamer.pla$ org.freed 7057 u0_a50 28 ??? ??? ??? ??? /dev/urandom org.freed 7057 u0_a50 30 ??? ??? ??? ??? anon_inode:[eventfd] ... ... org.freed 7057 u0_a50 84 ??? ??? ??? ??? socket:[294096] org.freed 7057 u0_a50 85 ??? ??? ??? ??? socket:[294097] org.freed 7057 u0_a50 90 ??? ??? ??? ??? socket:[289744] org.freed 7057 u0_a50 91 ??? ??? ??? ??? socket:[289745] --------- 1) PLAY -> EXIT, there are 6 items with prefix <socket:]>, 2) Just repeat the steps above to PLAY->EXIT,counting the items that contain the prefix "socket:", there are 8 items 3) ... 10 items 4) ... 12 items ... Each time PLAY => EXIT, 2 FDS will be leaked. AFAIK, many OS have limits on the number of FDS that can be opened in a process, usually not exceeding 1024. On my device, I can use a script to perform the above operation, and can't play video in a few minutes with error message: --- E MemoryHeapBase: error creating ashmem region: Too many open files --- It seems can't see any useful information in log, How to investigate fd leak, any debug tools or methods ?
Created attachment 362394 [details] fd_leak_gst_log_level_5 Anyway, with a level 5 log, experts might be able to see useful information from the log file. -)
This might be fixed already by commit 085f875a249ba73cf24e42c72ba811ab461efa6d Author: Philippe Renon <philippe_renon@yahoo.fr> Date: Fri Sep 15 15:04:02 2017 +0200 player: introduce helper method to remove seek source this incidentally fixes a missing g_source_destroy() call in _main() https://bugzilla.gnome.org/show_bug.cgi?id=787727 can you confirm?
I have confirmed it again, because 1.12.3 has merged this submission, so my code contains this change, probably not here caused this issure.
A little bit of progress： If playbin3, no leak; If playbin2, 2 fds are leaked each time.
Created attachment 362743 [details] playbin2_gstleaks_log_PC Addition. ( ubuntu 16.04 + gstreamer 12.3) playbin2(at the end, gstleaks tells us leaks detected.): shakin@shakin-dev:~/Desktop$ GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7" GST_DEBUG_COLOR_MODE=off GST_DEBUG_FILE='/home/shakin/work/log/gst.log' GST_DEBUG_DUMP_DOT_DIR='/home/shakin/work/log' gst-launch-1.0 playbin uri=http://10.9.44.116/test.mp4 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Redistribute latency... ^Chandling interrupt. ＜＝ ctrl + c Interrupt: Stopping pipeline ... Execution ended after 0:00:02.409864777 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ** (gst-launch-1.0:5607): WARNING **: Leaks detected Useful info： --- 0:00:00.207457856 6063 0x919a00 TRACE GST_TRACER gsttracerrecord.c:111:gst_tracer_record_build_format: object-alive.class, type-name=(structure)"value\,\ type\=\(type\)gchararray\,\ related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;", address=(structure)"value\,\ type\=\(type\)gpointer\,\ related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;", description=(structure)"value\,\ type\=\(type\)gchararray\,\ related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;", ref-count=(structure)"value\,\ type\=\(type\)guint\,\ related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;", trace=(structure)"value\,\ type\=\(type\)gchararray\,\ related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;"; 0:00:00.207572522 6063 0x919a00 DEBUG GST_TRACER gsttracerrecord.c:125:gst_tracer_record_build_format: new format string: object-alive, type-name=(string)%s, address=(gpointer)%p, description=(string)%s, ref-count=(uint)%u, trace=(string)%s; 0:00:02.568540981 6063 0x919a00 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstAudioClock, address=(gpointer)0x7fa69c365290, description=(string)<GstPulseSinkClock>, ref-count=(uint)1, trace=(string); 0:00:02.568546666 6063 0x919a00 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstPad, address=(gpointer)0x7fa69c1ed6c0, description=(string)<pulsesink0:sink>, ref-count=(uint)1, trace=(string); 0:00:02.568551207 6063 0x919a00 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstPad, address=(gpointer)0x7fa69c1ec4c0, description=(string)<xvimagesink0:sink>, ref-count=(uint)1, trace=(string); 0:00:02.568555324 6063 0x919a00 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstPulseSink, address=(gpointer)0x7fa69c364be0, description=(string)<pulsesink0>, ref-count=(uint)1, trace=(string); 0:00:02.568559260 6063 0x919a00 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstXvImageSink, address=(gpointer)0x7fa69c2091f0, description=(string)<xvimagesink0>, ref-count=(uint)1, trace=(string); --- Ｗhat does this mean, and where might the problem be? So confused...Advice please．（*>.<*） playbin3: shakin@shakin-dev:~/Desktop$ GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7" GST_DEBUG_COLOR_MODE=off GST_DEBUG_FILE='/home/shakin/work/log/gst.log' GST_DEBUG_DUMP_DOT_DIR='/home/shakin/work/log' gst-launch-1.0 playbin3 uri=http://10.9.44.116/test.mp4 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Redistribute latency... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock ^Chandling interrupt. <= ctrl + c Interrupt: Stopping pipeline ... Execution ended after 0:00:02.668387121 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... No warning, everything is ok!
I have been verified 1.10.3 on ubuntu 16.04 and there is no leak detected. I'm going to try to compare 1.12.0 and 1.12.1, It's not sure,but there's a big change to the floating reference between these two versions. Anyone can reproduce this by executing the following command line ? GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7" GST_DEBUG_COLOR_MODE=off GST_DEBUG_FILE='/home/shakin/work/log/gst.log' GST_DEBUG_DUMP_DOT_DIR='/home/shakin/work/log' gst-launch-1.0 playbin uri=http://10.9.44.116/test.mp4
Both 1.12.0/1.12.1 are OK. No "Leaks detected" warning.
After repeated comparison, and final point to this submission: b4899a5a6575 --- commit b4899a5a6575bd62786174d225a58c0f86499d13 (patch) tree 0aeddb8c91ea6df3d2530811d5cab515c6d7f6ef parent f996b056444164e72886451963649733a9ae013e (diff) playbin: Make sure to ref_sink() any sinks before calling activate_sink() It is forwarding messages to the playbin bus, thus forwarding messages that contain a floating reference to the application. This generally makes bindings unhappy, we must not leak floating references to them. Diffstat -rw-r--r-- gst/playback/gstplaybin2.c 18 ----- It's not clear yet,but just revert this submission, make <leaks tracer> happy.
Created attachment 362867 [details] [review] fix twice call ref_sink cause leaks issures proposed patch
commit f9155a04c11b30dae35d7c17617be2cb2f5993f3 (HEAD -> master) Author: shakin chou <shakin@outlook.com> Date: Fri Nov 3 11:39:54 2017 +0800 playbin: Don't ref_sink() the sinks twice Since we're already sunk floating reference, we shouldn't call ref_sink again, which increases the ref_count and cause leaks. https://bugzilla.gnome.org/show_bug.cgi?id=789547
Should be backported to 1.12.4