Memory leaks from dc_field_add_string

[glance-]

When doing a download, with example dctool, built with asan, one can clearly see the memory leaks from the strdup happening in the field-cache:

    #0 0x7d4d7b32478c in strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:617
    #1 0x645f8c5da40f in dc_field_add_string ../../libdivecomputer/src/field-cache.c:26
    #2 0x645f8c5da654 in dc_field_add_string_fmt ../../libdivecomputer/src/field-cache.c:52
    #3 0x645f8c561ad9 in add_sensor_state ../../libdivecomputer/src/shearwater_predator_parser.c:461
    #4 0x645f8c567043 in shearwater_predator_parser_cache ../../libdivecomputer/src/shearwater_predator_parser.c:973
    #5 0x645f8c560f4a in shearwater_predator_parser_get_datetime ../../libdivecomputer/src/shearwater_predator_parser.c:349
    #6 0x645f8c4b52e3 in dc_parser_get_datetime ../../libdivecomputer/src/parser.c:380
    #7 0x645f8c4a7cbe in dctool_xml_output_write ../../libdivecomputer/examples/output_xml.c:255
    #8 0x645f8c4a62d5 in dctool_output_write ../../libdivecomputer/examples/output.c:61
    #9 0x645f8c49ef5c in dive_cb ../../libdivecomputer/examples/dctool_download.c:92
    #10 0x645f8c56cefd in shearwater_petrel_device_foreach ../../libdivecomputer/src/shearwater_petrel.c:339
    #11 0x645f8c4b30b0 in dc_device_foreach ../../libdivecomputer/src/device.c:423
    #12 0x645f8c49fddd in download ../../libdivecomputer/examples/dctool_download.c:227
    #13 0x645f8c4a0de6 in dctool_download_run ../../libdivecomputer/examples/dctool_download.c:360
    #14 0x645f8c49d0af in main ../../libdivecomputer/examples/dctool.c:312
    #15 0x7d4d7ae2a600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59
    #16 0x7d4d7ae2a717 in __libc_start_main_impl ../csu/libc-start.c:360
    #17 0x645f8c499234 in _start (libdivecomputer-build/examples/dctool+0x66234) (BuildId: 506f83238fb80c0b06b6bbd4ec421c6fec390b98)

This is because the dc_parser_deallocate has no clue about the value strings kept in the struct dc_field_cache, and thus can't free them.

The 3 parsers using the dc_field_cache should either have a destroy function added to them which frees the cached strings or have their existing destroy function updated to free the cached strings.

[mikeller]

Good catch, and your analysis is spot on.

dc_field_add_string() calls strdup() on the value, but there is no counterpart that frees those heap-allocated strings when a parser is destroyed. Confirmed from source:

• The shearwater Predator and Petrel vtables both have NULL for the destroy slot — so nothing is called at all.
• The Garmin parser vtable is the same.
• The Suunto EON Steel parser does have a suunto_eonsteel_parser_destroy, but it only frees type_desc; it misses cache.strings[].value.

The fix is to add a dc_field_cache_free() helper that iterates the strings[] array and frees each value pointer (only value — desc is documented as a static allocation), then call it from each parser's destroy function. One additional subtlety worth noting: shearwater_predator_parser_cache() does memset(&parser->cache, 0, …) before populating the cache. That is safe today because parser->cached prevents re-entry, but it would silently leak if cached were ever reset without going through a proper clear first, so the helper should be called there too.

PR #130 implements this fix: #130

There is also a draft PR #131 that adds an ASAN/UBSAN build job to CI so leaks like this fail the build automatically on push: #131. One caveat worth noting there: libdc currently has no sample dive-log fixtures in the repo, so the sanitizer job runs over make distcheck only and won't exercise the parser paths directly. Wiring in a dctool parse harness over committed raw dumps is a planned follow-up.