memory leak when reconnection to camera using gstreamer on TX1 platform

Nicolas Dufresne nicolas at ndufresne.ca
Thu Dec 13 17:33:08 UTC 2018


Le mardi 11 décembre 2018 à 20:44 -0600, oona a écrit :
> Hi,
> 
> Thanks for your reply.
> 
> I refactor my application, limiting the appsink as:
>     gst_app_sink_set_emit_signals((GstAppSink*)g_appsink, true);
>     gst_app_sink_set_drop((GstAppSink*)g_appsink, true);
>     gst_app_sink_set_max_buffers((GstAppSink*)g_appsink, 1);
> 
> unrefing gstSample in time like function NewFrame() in:  github
> <https://github.com/rticommunity/rticonnextdds-videodemo-android/blob/master/jni/ConnextGstreamer.cxx> 
> .
> 
> Now, the memory does not increase for each reconnection. However, for the
> first time, the memory will rise from 80M to 120M, later it is floating
> around 120M.
> 
> Moreover, I use valgrind to test the memory leakage, the report is:
> ==813== LEAK SUMMARY:
> ==813==    definitely lost: 20,854 bytes in 49 blocks
> ==813==    indirectly lost: 5,281 bytes in 80 blocks
> ==813==      possibly lost: 8,572 bytes in 73 blocks
> ==813==    still reachable: 135,825,332 bytes in 23,583 blocks
> ==813==                       of which reachable via heuristic:
> ==813==                         stdstring          : 97 bytes in 1 blocks
> ==813==                         length64           : 2,208 bytes in 51
> blocks
> ==813==                         newarray           : 2,352 bytes in 36
> blocks
> ==813==         suppressed: 0 bytes in 0 blocks
> 
> without "definitely" details in the report, we guess that the memory leakage
> happens in the gstreamer lib.
> 
> Could you help us? thanks a lot!

You can use GStreamer leak tracer to get the list of still allocated
blocks, might give you a hint, though it's more likely an application
issue here.

GST_TRACERS=leak GST_DEBUG=GST_TRACER:7 ./your-app

> 
> 
> Nicolas Dufresne-5 wrote
> > Le jeudi 29 novembre 2018 à 03:59 +0000, oonamao(毛江云) a écrit :
> > > Hi all,
> > >  
> > > This is Oona, a junior software engineer. I send this email to ask your
> > > help about my gstreamer application:
> > > Recently, I met a memory leak problem on TX1 platform, when my gstreamer
> > > application tried to reconnect to the camera by rtsp. 
> > > Moreover, the tegra I’m using is:
> > > # R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t210ref, EABI:
> > > aarch64, DATE: Fri Mar  2 04:58:16 UTC 2018
> > > Gstreamer is:
> > > gst-inspect-1.0 version 1.8.1
> > > GStreamer 1.8.3
> > > https://launchpad.net/distros/ubuntu/+source/gstreamer1.0
> > 
> > This is relatively old, if it's an upstream bug, it is likely fixed.
> > 
> > >  
> > > Problem Details:
> > > 1.      The application will call gst_init() at the very first, then
> > > builds pipleline as “rtspsrc
> > > location=rtsp://${usrname}:${pwd}@${ip}:${port}/cam/realmonitor?channel=1&subtype=0
> > > protocols=tcp ! rtph264depay ! h264parse ! omxh264dec ! video/x-raw,
> > > format=NV12 ! appsink sync=false async=false name=appsink1”. As expected,
> > > it gets data from camera. By `top` commands, I can see its
> > > occupied-memory is ~108M;
> > > (disable ${ip})
> > 
> > Though, most of these report are related to miss-used of appsink.
> > appsink is non leak and have inifit queues by default. Make sure you
> > limite that queue and pop and unref buffers properly.
> > 
> > > 2.      Of course, the application fails to get data. And the application
> > > is trying to reconnect the pipeline periodically. It is still occupied
> > > ~108M;
> > > (enable ${ip})
> > > 3.      The application succeeds to get video again. However, the memory
> > > rises to ~180M!
> > > After trying 2,3 for times, I finds that: the memory will increase by
> > > -80M each time when it succeed in reconnection.
> > >  
> > > The following code segment is the reconnection (first close() then
> > > open()). I think I have unref all the resources in close(), in addition,
> > > I unref gst-sample, gst-message in time.
> > > ```
> > > int GSTCameraMini::open() {
> > >   this->m_camera_state = CAM_INIT; 
> > >   this -> build_pipeline(); 
> > >   gst_element_set_state(this -> pipeline, GST_STATE_PLAYING);
> > >   return 0;
> > > }
> > > 
> > > int GSTCameraMini::close() {
> > >   this->m_camera_state = CAM_OFFLINE; 
> > >   gst_element_set_state(this -> pipeline, GST_STATE_NULL);
> > >   // unref appsink
> > >   gst_object_unref(G_OBJECT(this -> appsink));
> > >   // unref bus
> > >   gst_object_unref(G_OBJECT(this -> bus));
> > >   // unref pipeline
> > >   gst_object_unref(G_OBJECT(this -> pipeline)); 
> > >   return 0;
> > > }
> > > ```
> > > I have no idea where goes wrong, and this problem makes me headache for a
> > > long time. It is a bug from gstreamer or other?
> > > Sincerely looking forward to your reply.
> > >  
> > > Best & Regards,
> > > Oona
> > >  
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > 
> > gstreamer-devel at .freedesktop
> > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > 
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at .freedesktop
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > 
> > 
> > signature.asc (201 bytes)
> > <http://gstreamer-devel.966125.n4.nabble.com/attachment/4689075/0/signature.asc>
> 
> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list