Closed bobhairgrove closed 7 years ago
I just ran csvcheck
through a debugger with a breakpoint set on the library function csv_free()
. It was never called.
Seems like csv_fini()
needs to call it before returning.
After looking at some of the source code for csvutils
, and re-reading the man csv
page, it seems that the responsibility for calling csv_free()
is left up to the caller. However, I am wondering if it would be better design to have csv_fini()
call this? Calling csv_free()
multiple times is never a problem because after calling it, the pointer to the freed memory block is set to NULL. However, it is not orthogonal to call csv_init()
, process the data, then call csv_fini()
, and THEN still have to call csv_free()
. Just IMHO.
If you'd rather leave it this way, we can close this issue now. However, it would be nice if you could fix the memory leaks in csvutils
.
The complement to csv_init
is csv_free
, csv_fini
is part of the parsing process and the same parser object can continue to be used to parse new CSV data after calling csv_fini
without having to call csv_free
or csv_init
again.
OK, I am closing this now that it is clear that the errors from valgrind are coming from csvutils
and not from libcsv
.
These memory leaks were reported by running
csvcheck
,csvcut
andcsvgrep
undervalgrind
, but some of them seem to be coming fromlibcsv
. However,csvcount
passed the leak test, so the problems might be incsvutils
.I am attaching the CSV file I used to run these: my_test.csv.zip
csvcheck:
csvcut:
csvgrep: