I’m thinking about an interim measures for a memory leak issue.
→ Refer: https://devtalk.nvidia.com/default/topic/1035330/jetson-tx2/-mmapi-r28-2-r28-1-deinitplane-of-nvvideoencoder-memory-leak-/
This issue (memory leak) occurs in dynamic resolution changing.
Outline of processing
(1) Stop Device
- Stop Converter and Encoder (STREAMOFF)
- De-allocate Buffers
- Stop Worker Thread (send EOS and waitForDqThread())
(2) Re-setting and Re-start - Configure Converter and Encoder
- Allocate Buffers
- Set Callback and Worker Thread
- Start Converter and Encoder (STREAMON)
I thought that to delete Converter and Encoder objects makes the available memory back.
Then I added a process to the above sequence between (1) and (2):
- Delete Converter and Encoder
Unfortunately, “Segmentation Fault” error occured in the destructor.
As a result of the analysis, I found an issue in v4l2_ioctl(fd, VIDIOC_REQBUFS, 0) of reqbuf().
When this ioctl called twice, after about 160msec “Segmentation Fault” occurs.
In the second called deinitPlane(),
de-allocation of buffers(data) and NvBuffer are executed normally using a variable of number of buffers.
In the NvV4l2Element destructor, deinitPlane() methods are called.
When the user program calls deinitPlane() and delete object, deinitPlane() is called twice.
Anyone can reproduce this issue easily by calling deinitPlane() twice.
NvV4l2ElementPlane object has number of buffers as variable num_buffers.
If this issue will not be corrected soon, it can be handled easily, I think.
(I have not yet tested it.)
[NvV4l2ElementPlane::deinitPlane()]
Original
reqbufs(memory_type, 0);
Modified
if (num_buffers > 0) reqbufs(memory_type, 0);
Best Regards