Closed cebtenzzre closed 3 years ago
Thanks for reporting and particularly for the diagnostics.
Was fixed as of f4c821c in the develop branch and will be merged into master branch at next release. Meanwhile you can compile from develop branch.
Whoops, I saw recent commits in master and figured it wasn't too far from develop. Perhaps I should make an AUR package for that branch so I don't run into old bugs as often.
Perhaps I should make an AUR package for that branch
You're welcome to, but really we should be more pro-active at back-porting clear-cut bugs so that it's not necessary. I still have my L-plates on as a package maintainer and @sahib has gotten busy with other projects and had to step back a bit.
I'm gearing up for a new point release soon, I feel that #492 is a good foundation for that.
Steps to reproduce
Actual behavior
rmlint crashes with this output:
Or, with AddressSanitizer:
Expected behavior
rmlint prints this output:
Analysis
Here, checksum_str and checksum_size are initialized. https://github.com/sahib/rmlint/blob/427791ca7c9ffa66b2c666b6b01874c5e165fae6/lib/formats/csv.c#L73-L74 Here, if
file->digest
is NULL indicating a unique file, a block of size one is allocated with g_slice_alloc0 and stored in checksum_str, without changing checksum_size. This behavior was introduced by commit 1b06eb3d0787b42a3159573ee970a5a885a3ccae. https://github.com/sahib/rmlint/blob/427791ca7c9ffa66b2c666b6b01874c5e165fae6/lib/formats/csv.c#L81-L84 Here, g_slice_free1 is called. checksum_size is still zero from when it was initialized, even though checksum_str points to a block of size one. https://github.com/sahib/rmlint/blob/427791ca7c9ffa66b2c666b6b01874c5e165fae6/lib/formats/csv.c#L101-L103 From the glib docs, regarding g_slice_free1: