V4l2allocator: orphan buffers are not freed
We have a decoding pipeline which is changed repeatedly (changing view) which means that the pipeline is released and a new one is setup. This works fine in most cases, but it seems to be a timing issue/corner case where there are some outstanding buffers when the buffer pool is stopped.
This is from the end of dec215 file:v4l2h264dec215.txtv4l2h264dec214.txt 0:10:05.376222798 [33m 1778 [00m 0x55a2602470 [37mDEBUG [00m [00m v4l2bufferpool gstv4l2bufferpool.c:975:gst_v4l2_buffer_pool_stop:v4l2h264dec215:pool0:src [00m stopping pool 0:10:05.376273298 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m bufferpool gstbufferpool.c:382:do_free_buffer:v4l2h264dec215:pool0:src [00m freeing buffer 0x7f4c007120 (20 left) 0:10:05.376303048 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m plane 0 of buffer 0 released 0:10:05.376341173 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m plane 1 of buffer 0 released 0:10:05.376362548 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:374:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m buffer 0 released : : 0:10:05.378239923 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m bufferpool gstbufferpool.c:382:do_free_buffer:v4l2h264dec215:pool0:src [00m freeing buffer 0x55a26f2000 (2 left) 0:10:05.378267173 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m plane 0 of buffer 20 released 0:10:05.378296298 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m plane 1 of buffer 20 released 0:10:05.378316923 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:374:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m buffer 20 released 0:10:05.378344173 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m bufferpool gstbufferpool.c:382:do_free_buffer:v4l2h264dec215:pool0:src [00m freeing buffer 0x7f7001ac60 (1 left) 0:10:05.378371048 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m plane 0 of buffer 21 released 0:10:05.378399673 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m plane 1 of buffer 21 released 0:10:05.378420423 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:374:gst_v4l2_allocator_release:v4l2h264dec215:pool0:src:allocator [00m buffer 21 released 0:10:05.392006048 [33m 1778 [00m 0x55a2602470 [37mDEBUG [00m [00m bufferpool gstbufferpool.c:192:gst_buffer_pool_finalize:v4l2h264dec215:pool0:src [00m 0x7f3004a8b0 finalize
We can see that the buffer pool is finalized with outstanding buffers that in this case is a DMA buffer so there is a file leakage which in our case will lead to a crash when the number of files reaches the limit. If we compare with a working case (dec214 file): 0:10:05.498446298 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m bufferpool gstbufferpool.c:382:do_free_buffer:v4l2h264dec214:pool0:src [00m freeing buffer 0x7f54031480 (0 left) 0:10:05.498474423 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec214:pool0:src:allocator [00m plane 0 of buffer 21 released 0:10:05.498502173 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:356:gst_v4l2_allocator_release:v4l2h264dec214:pool0:src:allocator [00m plane 1 of buffer 21 released 0:10:05.498523298 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:374:gst_v4l2_allocator_release:v4l2h264dec214:pool0:src:allocator [00m buffer 21 released 0:10:05.498566673 [33m 1778 [00m 0x55a2602470 [37mDEBUG [00m [00m v4l2allocator gstv4l2allocator.c:768:gst_v4l2_allocator_stop:v4l2h264dec214:pool0:src:allocator [00m stop allocator 0:10:05.498593423 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:393:gst_v4l2_allocator_free:v4l2h264dec214:pool0:src:allocator [00m freeing plane 0 of buffer 0 0:10:05.498640673 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:393:gst_v4l2_allocator_free:v4l2h264dec214:pool0:src:allocator [00m freeing plane 1 of buffer 0 : : 0:10:05.500829298 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:393:gst_v4l2_allocator_free:v4l2h264dec214:pool0:src:allocator [00m freeing plane 0 of buffer 21 0:10:05.500873423 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:393:gst_v4l2_allocator_free:v4l2h264dec214:pool0:src:allocator [00m freeing plane 1 of buffer 21 0:10:05.500916548 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:417:gst_v4l2_allocator_dispose:v4l2h264dec214:pool0:src:allocator [00m called 0:10:05.500940048 [33m 1778 [00m 0x55a2602470 [33;01mLOG [00m [00m v4l2allocator gstv4l2allocator.c:434:gst_v4l2_allocator_finalize:v4l2h264dec214:pool0:src:allocator [00m called 0:10:05.545140173 [33m 1778 [00m 0x55a2602470 [37mDEBUG [00m [00m bufferpool gstbufferpool.c:192:gst_buffer_pool_finalize:v4l2h264dec214:pool0:src [00m 0x7f0c053410 finalize As we can see from the working case is allocator_stop called which triggers the freeing and dispose of the allocator and all buffers are released.
The remedy solution for us is to disable the orphan feature, seems to work fine, not seen any issues with that. But since this feature is enabled by default is it probably not the wanted end solution and there can be some drawbacks that we have not seen yet.