[task #15567] Converting hh:mm:ss and dd:mm:ss notations to degrees and vice vesa

[Kartik Ohri]

Follow-up Comment #44, task #15567 (project gnuastro):

I tried various operators to find the issue. This issue is not caused by the
units operator. The memory leak is evident as follows this was a simple
-c"arith c1 c1 +" argument.

The table was as follows
1
2

==14516== HEAP SUMMARY:
==14516==     in use at exit: 154 bytes in 5 blocks
==14516==   total heap usage: 1,372 allocs, 1,367 frees, 127,448 bytes
allocated
==14516== 
==14516== 2 bytes in 1 blocks are definitely lost in loss record 1 of 3
==14516==    at 0x483A7F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==14516==    by 0x33F32C: gal_checkset_allocate_copy (checkset.c:154)
==14516==    by 0x4C0ED4: gal_type_from_string (type.c:492)
==14516==    by 0x361244: gal_options_read_check (options.c:1520)
==14516==    by 0x361A5F: options_set_from_name (options.c:1857)
==14516==    by 0x361CD1: options_parse_file (options.c:1949)
==14516==    by 0x361F09: gal_options_parse_config_files (options.c:2034)
==14516==    by 0x36233F: gal_options_read_config_set (options.c:2150)
==14516==    by 0x11092F: ui_read_check_inputs_setup (ui.c:1104)
==14516==    by 0x10D61D: main (main.c:46)
==14516== 
==14516== 152 (32 direct, 120 indirect) bytes in 1 blocks are definitely lost
in loss record 3 of 3
==14516==    at 0x483A7F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==14516==    by 0x10DD23: ui_outcols_add_new_to_end (ui.c:426)
==14516==    by 0x10E051: ui_columns_prepare (ui.c:567)
==14516==    by 0x10F2FB: ui_preparations (ui.c:973)
==14516==    by 0x11096B: ui_read_check_inputs_setup (ui.c:1125)
==14516==    by 0x10D61D: main (main.c:46)
==14516== 
==14516== LEAK SUMMARY:
==14516==    definitely lost: 34 bytes in 2 blocks
==14516==    indirectly lost: 120 bytes in 3 blocks
==14516==      possibly lost: 0 bytes in 0 blocks
==14516==    still reachable: 0 bytes in 0 blocks
==14516==         suppressed: 0 bytes in 0 blocks
==14516==

I suspect this issue is caused because the memory allocated to output columns
is not freed after displaying the output. I don't know to fix this. Should I
file a new bug ?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/task/?15567>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/