The coding period has started today! In the last blog post related to GSOC, I said “Here are the plans that I currently have. As with all plans, they are subject to change.” They did indeed change since I found a tool to find memory leaks.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/zardshard/2023-05-29_gsoc_2023_first_course_of_action_fix_memory_leaks/
My one patch to the code base was getting the power management to exit gracefully when its services weren’t needed on my desktop machine. It was reduced from 2 lines of code to 1 when somebody else noticed that smart pointers would make my
delete command redundant. My C++ experience is limited to code prior to 2011 so C++ coding isn’t my strong suit any more.
I’m glad you are applying what you know about address sanitizing to fix memory leaks. I’m not surprised that Haiku needs some care due to development by a small team and starting development over 20 years ago. Thanks for providing that care!
It’s a good thing to work and share knowledge on, and I like how you have been active researching, discussing and improving things!
Well done and keep up the good work!
You might also try running the clang static analyzer against the code. It’s not perfect so it generates a bunch of false positives and makes mistakes, but it does find real bugs. the scan build tool gives you an HTML report of all the potential issues, including memory leaks, use-after-free, potential garbage values, etc. It might save you some time to find more than one leak at a time, across the whole app.
Hello; thanks for working through those memory leaks and issues – it’s really great and will end up with a better tool for it.
Interesting to peek in such development which establish a more stable envioronment – finally for more applications and even for the whole system …
Thanks for C L E A N - U P !
Fixing memory leaks is always good but I would advise you keep the law of diminishing returns in mind. Each subsequent leak could get harder to find. Finding memory leaks is also one of those thankless and frustrating tasks that can quickly lead to burnout. So I would advise to make sure you take some time to do other work as well, like fixing known bugs or adding features, things easier to do that can give you some “quick wins”.
Because 4 to 6 weeks of fixing memory leaks does not sound fun to me at all.
PulkoMandy pointed out that 4 to 6 weeks around half of GSoC, and that it would be better to focus on things that a hobbyist developer working a couple of hours per week could not do easily.
That advice is good and seems rather obvious in retrospect. Therefore, I won’t be fixing all the memory leaks. Just a couple.