There are some memory leaks reported for nc_test4/tst_xplatform2.c. When I look at the code I see that some nc_free_vlen() statements have been commented out:
/* Free our vlens. */
for (i = 0; i < DIM3_LEN; i++)
for (j = 0; j < NUM_VL; j++)
nc_free_vlen(&(data_in[i].data[j]));
When uncommented (as they should be, by looking at the code), the memory leaks go away, but a memory use after free error occurs in test function check_file_3(). Presumably it was this memory problem which lead to the nc_free_vlen calls being commented out.
The problem occurs writing a nested vlen attribute, and then reading the vlen attribute before enddef, so it has not yet been written to the file.
In that case, the read does not apparently get a copy of the vlen data, but gets pointers to the actual vlen data in memory. When nc_free_vlen() is called on data_in, it frees the vlen data in memory, and the later attempt to sync the file fails when this is caught by the memory sanitizer.
There is no problem if enddef is called before the reading of the attribute. In that case, the read gets a copy of the vlen data, as it should, which it can then free without affecting library pointers.
I don't have a good idea what to do to fix this yet.
Not sure if this will happen with vars too.
There are some memory leaks reported for nc_test4/tst_xplatform2.c. When I look at the code I see that some nc_free_vlen() statements have been commented out:
When uncommented (as they should be, by looking at the code), the memory leaks go away, but a memory use after free error occurs in test function check_file_3(). Presumably it was this memory problem which lead to the nc_free_vlen calls being commented out.
The problem occurs writing a nested vlen attribute, and then reading the vlen attribute before enddef, so it has not yet been written to the file.
In that case, the read does not apparently get a copy of the vlen data, but gets pointers to the actual vlen data in memory. When nc_free_vlen() is called on data_in, it frees the vlen data in memory, and the later attempt to sync the file fails when this is caught by the memory sanitizer.
There is no problem if enddef is called before the reading of the attribute. In that case, the read gets a copy of the vlen data, as it should, which it can then free without affecting library pointers.
I don't have a good idea what to do to fix this yet.
Not sure if this will happen with vars too.