valgrind reports possible memory leak wen calling av_audio_convert

[pepijn-devries]

When I run the following code using valgrind (R -d "valgrind -s --track-origins=yes --leak-check=full")

fname <- system.file("samples/Synapsis-Wonderland.mp3", package = "av")
dest <- tempfile(fileext = ".wav")
av::av_audio_convert(fname, dest)

Valgrind reports a possible memory leak:

> 
> fname <- system.file("samples/Synapsis-Wonderland.mp3", package = "av")
> dest <- tempfile(fileext = ".wav")
> av::av_audio_convert(fname, dest)
Output #0, wav, to '/tmp/RtmporcY8o/file1a7951869028.wav':
  Metadata:
    ISFT            : Lavf60.16.100
  Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s
Could not update timestamps for skipped samples.
Adding audio frame 1150 at timestamp 30.01secCould not update timestamps for discarded samples.
Adding audio frame 1151 at timestamp 30.03sec - audio stream completed!
[1] "/tmp/RtmporcY8o/file1a7951869028.wav"
> 
> q()
Save workspace image? [y/n/c]: n
==6777== 
==6777== HEAP SUMMARY:
==6777==     in use at exit: 45,191,561 bytes in 13,600 blocks
==6777==   total heap usage: 47,221 allocs, 33,621 frees, 85,267,621 bytes allocated
==6777== 
==6777== 24 bytes in 1 blocks are possibly lost in loss record 126 of 1,681
==6777==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==6777==    by 0x4011E3D: UnknownInlinedFun (rtld-malloc.h:56)
==6777==    by 0x4011E3D: allocate_dtv_entry (dl-tls.c:679)
==6777==    by 0x4011E3D: allocate_and_init (dl-tls.c:704)
==6777==    by 0x4011E3D: tls_get_addr_tail (dl-tls.c:902)
==6777==    by 0x401559B: __tls_get_addr (tls_get_addr.S:55)
==6777==    by 0x29DBC446: _gnutls_fips_mode_enabled (fips.c:84)
==6777==    by 0x29DAAF91: _gnutls_rnd_preinit (random.c:119)
==6777==    by 0x29D9A35C: _gnutls_global_init (global.c:312)
==6777==    by 0x29D6719F: lib_init (global.c:524)
==6777==    by 0x4005236: call_init (dl-init.c:74)
==6777==    by 0x4005236: call_init (dl-init.c:26)
==6777==    by 0x400532C: _dl_init (dl-init.c:121)
==6777==    by 0x40015C1: _dl_catch_exception (dl-catch.c:211)
==6777==    by 0x400BEEB: dl_open_worker (dl-open.c:829)
==6777==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==6777== 
==6777== 228 bytes in 1 blocks are possibly lost in loss record 356 of 1,681
==6777==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==6777==    by 0x4011E3D: UnknownInlinedFun (rtld-malloc.h:56)
==6777==    by 0x4011E3D: allocate_dtv_entry (dl-tls.c:679)
==6777==    by 0x4011E3D: allocate_and_init (dl-tls.c:704)
==6777==    by 0x4011E3D: tls_get_addr_tail (dl-tls.c:902)
==6777==    by 0x401559B: __tls_get_addr (tls_get_addr.S:55)
==6777==    by 0x30C9C9B4: UnknownInlinedFun (memory-util.c:12)
==6777==    by 0x30C9C9B4: UnknownInlinedFun (fileio.c:452)
==6777==    by 0x30C9C9B4: read_virtual_file_at.constprop.0 (fileio.c:562)
==6777==    by 0x30C97664: UnknownInlinedFun (fileio.h:85)
==6777==    by 0x30C97664: UnknownInlinedFun (fileio.h:88)
==6777==    by 0x30C97664: UnknownInlinedFun (fileio.c:815)
==6777==    by 0x30C97664: get_process_threads.constprop.0 (process-util.c:1682)
==6777==    by 0x30C8B9CC: UnknownInlinedFun (hashmap.c:292)
==6777==    by 0x30C8B9CC: hashmap_trim_pools (hashmap.c:281)
==6777==    by 0x30C18CAD: cleanup_pools (hashmap.c:306)
==6777==    by 0x40010F1: _dl_call_fini (dl-call_fini.c:43)
==6777==    by 0x400506D: _dl_fini (dl-fini.c:114)
==6777==    by 0x4D18FD5: __run_exit_handlers (exit.c:111)
==6777==    by 0x4D1911D: exit (exit.c:141)
==6777==    by 0x4ADE9C0: Rstd_CleanUp (sys-std.c:1246)
==6777== 
==6777== 672 bytes in 1 blocks are possibly lost in loss record 447 of 1,681
==6777==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==6777==    by 0x4011F60: UnknownInlinedFun (rtld-malloc.h:56)
==6777==    by 0x4011F60: _dl_resize_dtv (dl-tls.c:493)
==6777==    by 0x4012903: _dl_update_slotinfo (dl-tls.c:807)
==6777==    by 0x4012A13: update_get_addr (dl-tls.c:914)
==6777==    by 0x401559B: __tls_get_addr (tls_get_addr.S:55)
==6777==    by 0x29DBC446: _gnutls_fips_mode_enabled (fips.c:84)
==6777==    by 0x29DAAF91: _gnutls_rnd_preinit (random.c:119)
==6777==    by 0x29D9A35C: _gnutls_global_init (global.c:312)
==6777==    by 0x29D6719F: lib_init (global.c:524)
==6777==    by 0x4005236: call_init (dl-init.c:74)
==6777==    by 0x4005236: call_init (dl-init.c:26)
==6777==    by 0x400532C: _dl_init (dl-init.c:121)
==6777==    by 0x40015C1: _dl_catch_exception (dl-catch.c:211)
==6777== 
==6777== LEAK SUMMARY:
==6777==    definitely lost: 0 bytes in 0 blocks
==6777==    indirectly lost: 0 bytes in 0 blocks
==6777==      possibly lost: 924 bytes in 3 blocks
==6777==    still reachable: 45,188,621 bytes in 13,576 blocks
==6777==                       of which reachable via heuristic:
==6777==                         newarray           : 4,264 bytes in 1 blocks
==6777==         suppressed: 0 bytes in 0 blocks
==6777== Reachable blocks (those to which a pointer was found) are not shown.
==6777== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6777== 
==6777== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

As I'm using av_convert_audio in my package, this is popping up in the extended CRAN checks. Is this something that can be fixed?

[pepijn-devries]

Maybe related to #43

[jeroen]

Small one time memory leaks are generally harmless, and sometimes impossible to avoid. IIRC you can set some valgrind option or variable to suppress notices about memory leaks.

[pepijn-devries]

Thanks. I will see if I can set some valgrind flags to ignore these small leaks.