memory leak when reconnection to camera using gstreamer on TX1 platform

[oona]

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!


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/