for (const auto& t : trees) {
trees.push_back(buf);
auto ln = (leaf_node*)((uint8_t*)t.data() + sizeof(tree_header));
You could replace t with a non-owning std::span constructed from trees[i], but it's still wrong to push into trees while iterating over it (the for loop will still error out).
IMO you should replace the foreach loop with a for (size_t i = 0; i < trees.size(); i++), and either replace all uses of t with trees[i] or apply the std::span transformation as I mentioned above. I'd also comment that trees is being pushed onto, so you can't replace the indexed loop with a foreach.
TBH pushing onto a loop while iterating over it is quite tricky to understand. I'm not sure if it's necessary complexity, or if you can refactor to preserve user-facing functionality without pushing onto a loop while iterating over it; I don't actually know how your program works.
Are there any remaining latent or crashing bugs past this? I don't know! I applied the for-loop fix and wrote trees[i] twice, and the resulting ASAN-enabled binary seems to process my partition without crashing...
I think this is the same bug as #47 and possibly #39.
Oops! That's a stupid bug, thank you for doing the detective work. I've replaced the std::vector with a std::list instead, which doesn't have a problem with iterator invalidation.
When I install the
ntfs2btrfs-git
AUR package and run, it crashes:When I rebuild with asan enabled and run again, it prints more information about the crash:
That was a doozy.
The bug is that
t
is a dangling reference:You could replace
t
with a non-owningstd::span
constructed fromtrees[i]
, but it's still wrong to push intotrees
while iterating over it (the for loop will still error out).IMO you should replace the foreach loop with a
for (size_t i = 0; i < trees.size(); i++)
, and either replace all uses oft
withtrees[i]
or apply thestd::span
transformation as I mentioned above. I'd also comment thattrees
is being pushed onto, so you can't replace the indexed loop with a foreach.TBH pushing onto a loop while iterating over it is quite tricky to understand. I'm not sure if it's necessary complexity, or if you can refactor to preserve user-facing functionality without pushing onto a loop while iterating over it; I don't actually know how your program works.
Are there any remaining latent or crashing bugs past this? I don't know! I applied the for-loop fix and wrote
trees[i]
twice, and the resulting ASAN-enabled binary seems to process my partition without crashing...I think this is the same bug as #47 and possibly #39.