Memleaks fixes #700
Merged
Memleaks fixes #700
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Suspecting the packet decoding failures which happen sometimes cause a memory leak. ==6284== 3,139,437 bytes in 3 blocks are possibly lost in loss record 3,795 of 3,797 ==6284== at 0x484E366: posix_memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==6284== by 0x4FBA544: av_malloc (mem.c:105) ==6284== by 0x4FA0559: av_buffer_alloc (buffer.c:82) ==6284== by 0x4FA05D1: av_buffer_allocz (buffer.c:95) ==6284== by 0x4FA0D7D: pool_alloc_buffer (buffer.c:369) ==6284== by 0x4FA0D7D: av_buffer_pool_get (buffer.c:407) ==6284== by 0x4AC122E: video_get_buffer (get_buffer.c:240) ==6284== by 0x4AC122E: avcodec_default_get_buffer2 (get_buffer.c:276) ==6284== by 0x4AB3BCA: ff_get_buffer (decode.c:1673) ==6284== by 0x4B0E243: alloc_picture (h264_slice.c:195) ==6284== by 0x4B0E243: h264_frame_start (h264_slice.c:528) ==6284== by 0x4B11E9E: h264_field_start (h264_slice.c:1601) ==6284== by 0x4B11E9E: ff_h264_queue_decode_slice (h264_slice.c:2132) ==6284== by 0x4B16986: decode_nal_units (h264dec.c:651) ==6284== by 0x4B16986: h264_decode_frame (h264dec.c:1047) ==6284== by 0x4AB1EEB: decode_simple_internal (decode.c:430) ==6284== by 0x4AB1EEB: decode_simple_receive_frame (decode.c:610) ==6284== by 0x4AB1EEB: decode_receive_frame_internal (decode.c:638) ==6284== by 0x4AB23FB: avcodec_send_packet (decode.c:735) ==6284== ==6284== 3,140,064 bytes in 6 blocks are still reachable in loss record 3,796 of 3,797 ==6284== at 0x484E366: posix_memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==6284== by 0x4FBA544: av_malloc (mem.c:105) ==6284== by 0x4FA0559: av_buffer_alloc (buffer.c:82) ==6284== by 0x4FA05D1: av_buffer_allocz (buffer.c:95) ==6284== by 0x4FA0D7D: pool_alloc_buffer (buffer.c:369) ==6284== by 0x4FA0D7D: av_buffer_pool_get (buffer.c:407) ==6284== by 0x4B0E36D: alloc_picture (h264_slice.c:248) ==6284== by 0x4B0E36D: h264_frame_start (h264_slice.c:528) ==6284== by 0x4B11E9E: h264_field_start (h264_slice.c:1601) ==6284== by 0x4B11E9E: ff_h264_queue_decode_slice (h264_slice.c:2132) ==6284== by 0x4B16986: decode_nal_units (h264dec.c:651) ==6284== by 0x4B16986: h264_decode_frame (h264dec.c:1047) ==6284== by 0x4AB1EEB: decode_simple_internal (decode.c:430) ==6284== by 0x4AB1EEB: decode_simple_receive_frame (decode.c:610) ==6284== by 0x4AB1EEB: decode_receive_frame_internal (decode.c:638) ==6284== by 0x4AB23FB: avcodec_send_packet (decode.c:735) ==6284== by 0x134FFB: motion_processor::run() (motion_processor.cpp:139) ==6284== by 0x13577C: bc_mproc_thread(void*) (motion_processor.cpp:853) ==6284== ==6284== 6,278,874 bytes in 6 blocks are still reachable in loss record 3,797 of 3,797 ==6284== at 0x484E366: posix_memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==6284== by 0x4FBA544: av_malloc (mem.c:105) ==6284== by 0x4FA0559: av_buffer_alloc (buffer.c:82) ==6284== by 0x4FA05D1: av_buffer_allocz (buffer.c:95) ==6284== by 0x4FA0D7D: pool_alloc_buffer (buffer.c:369) ==6284== by 0x4FA0D7D: av_buffer_pool_get (buffer.c:407) ==6284== by 0x4AC122E: video_get_buffer (get_buffer.c:240) ==6284== by 0x4AC122E: avcodec_default_get_buffer2 (get_buffer.c:276) ==6284== by 0x4AB3BCA: ff_get_buffer (decode.c:1673) ==6284== by 0x4B0E243: alloc_picture (h264_slice.c:195) ==6284== by 0x4B0E243: h264_frame_start (h264_slice.c:528) ==6284== by 0x4B11E9E: h264_field_start (h264_slice.c:1601) ==6284== by 0x4B11E9E: ff_h264_queue_decode_slice (h264_slice.c:2132) ==6284== by 0x4B16986: decode_nal_units (h264dec.c:651) ==6284== by 0x4B16986: h264_decode_frame (h264dec.c:1047) ==6284== by 0x4AB1EEB: decode_simple_internal (decode.c:430) ==6284== by 0x4AB1EEB: decode_simple_receive_frame (decode.c:610) ==6284== by 0x4AB1EEB: decode_receive_frame_internal (decode.c:638) ==6284== by 0x4AB23FB: avcodec_send_packet (decode.c:735)
==6284== 1,036,944 bytes in 2 blocks are possibly lost in loss record 3,790 of 3,797 ==6284== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==6284== by 0x66E9628: cv::fastMalloc(unsigned long) (in /usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0) ==6284== by 0x67B851B: ??? (in /usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0) ==6284== by 0x67AE636: cv::Mat::create(int, int const*, int) (in /usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0) ==6284== by 0x67AE98F: cv::Mat::create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0) ==6284== by 0x13354C: motion_processor::detect_opencv(AVFrame*) (motion_processor.cpp:577) ==6284== by 0x1355B2: detect (motion_processor.cpp:255) ==6284== by 0x1355B2: motion_processor::run() (motion_processor.cpp:182) ==6284== by 0x13577C: bc_mproc_thread(void*) (motion_processor.cpp:853) ==6284== by 0x736EA93: start_thread (pthread_create.c:447) ==6284== by 0x73FBA33: clone (clone.S:100)
Nothing new added, only sorting into categories and within categories was applied.
This might help against this big leak (representing 64 minutes of operation): ==16436== 684,426,964 bytes in 5,941 blocks are definitely lost in loss record 3,813 of 3,813 ==16436== at 0x484E366: posix_memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==16436== by 0x4FBD544: av_malloc (mem.c:105) ==16436== by 0x4FB85A9: av_image_alloc (imgutils.c:248) ==16436== by 0x1229A6: snapshot_writer::scale_frame(AVFrame*, bool&) (media_writer.cpp:612) ==16436== by 0x122B2F: snapshot_writer::write_frame(AVFrame*) (media_writer.cpp:659) ==16436== by 0x1231FF: push_packet (media_writer.cpp:522) ==16436== by 0x1231FF: push_packet (media_writer.cpp:471) ==16436== by 0x1231FF: snapshot_writer::feed(stream_packet const&) (media_writer.cpp:431) ==16436== by 0x139B13: recorder::run() (recorder.cpp:139) ==16436== by 0x7029BB3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33) ==16436== by 0x7370A93: start_thread (pthread_create.c:447) ==16436== by 0x73FDA33: clone (clone.S:100)
==16436== 1,934,398 bytes in 44,986 blocks are indirectly lost in loss record 3,809 of 3,813 ==16436== at 0x484DB80: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==16436== by 0x4FBD777: av_strdup (mem.c:275) ==16436== by 0x4FA8DD0: av_dict_set (dict.c:99) ==16436== by 0x1251D4: bc_streaming_hls_packet_write(bc_record*, stream_packet const&) (streaming.cpp:362) ==16436== by 0x12064C: bc_record::run() (bc-thread.cpp:434) ==16436== by 0x12173C: bc_device_thread(void*) (bc-thread.cpp:142) ==16436== by 0x7370A93: start_thread (pthread_create.c:447) ==16436== by 0x73FDA33: clone (clone.S:100) ==16436== ==16436== 3,779,364 (720,000 direct, 3,059,364 indirect) bytes in 45,000 blocks are definitely lost in loss record 3,810 of 3,813 ==16436== at 0x484E366: posix_memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==16436== by 0x4FBD544: av_malloc (mem.c:105) ==16436== by 0x4FBD70C: av_mallocz (mem.c:256) ==16436== by 0x4FA8E49: av_dict_set (dict.c:112) ==16436== by 0x1251D4: bc_streaming_hls_packet_write(bc_record*, stream_packet const&) (streaming.cpp:362) ==16436== by 0x12064C: bc_record::run() (bc-thread.cpp:434) ==16436== by 0x12173C: bc_device_thread(void*) (bc-thread.cpp:142) ==16436== by 0x7370A93: start_thread (pthread_create.c:447) ==16436== by 0x73FDA33: clone (clone.S:100)
andrey-utkin
force-pushed
the
memleaks-on-3.1.3
branch
from
923a7bd to
25f0d28
Compare
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From repeated automated testing (1 stream on continuous+motion) I conclude that these changes bring down total leakage from 100+ KB/s to 1KB/s.