Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions
Boris
@lokasan
The Day I Spent 6 Hours Chasing a Memory Leak in C++ A few weeks ago, I was working on a high-performance logging module for a real-time application in C++. Everything was running fine… until we left the app running overnight. Next morning? 2 GB of RAM usage. Oops.
1 reply
0 recast
0 reaction
Boris
@lokasan
The Symptom The process was slowly consuming more and more memory — a classic sign of a memory leak. I ran a quick task manager check, confirmed the trend, and then dove into the codebase. The suspicious code was a simple logger with an internal cache: void logMessage(const std::string& msg) { char* buffer = new char[msg.size() + 1]; strcpy(buffer, msg.c_str()); logQueue.push_back(buffer); } Looks harmless at first glance… until you realize: 👉 nothing frees that memory. And since we log constantly, this leaked on every call.
1 reply
0 recast
0 reaction
Boris
@lokasan
At first, I considered manually cleaning up with delete[] after processing each message. But that felt fragile and easy to forget in the long run. So I did what I should’ve done from the beginning: used std::unique_ptr. #include <memory> void logMessage(const std::string& msg) { auto buffer = std::make_unique<char[]>(msg.size() + 1); strcpy(buffer.get(), msg.c_str()); logQueue.push_back(std::move(buffer)); } Now the buffer will be freed automatically when unique_ptr goes out of scope or is removed from the queue. No manual cleanup, no leaks, and the system stays at a steady 80 MB under load.
1 reply
0 recast
0 reaction
Boris
@lokasan
To be sure, I ran Valgrind: valgrind --leak-check=full ./log_test Before: hundreds of bytes "definitely lost" on each run. After: clean report — 0 leaks.
0 reply
0 recast
0 reaction
