Closed Jaskowicz1 closed 2 months ago
as well as unique_ptr you may have to rehash the maps periodically by copying all data to a new one. This is the only way to force unordered map to release its buckets.
This does not seem to occur on Windows and currently looks like a Linux only bug...
I'm now working on this.
To further make this confusing, this leak does not happen on Mac OSX either. So it really is Linux only...
:thonk: I think i can look into that, ima test on my machine
The fix that @Mishura4 implemented doesn't seem to work. This also seems to be an issue with only libstdc++. Upgrading to a newer g++ fixes it (as long as you use that newer g++) as it appears newer versions of libstdc++ have this fixed.
updating to what? I'm on g++ 12.3.0 on my production machines, where the problem persists...? It's literally the latest available g++ on ubuntu 22.04.
The fix that @Mishura4 implemented doesn't seem to work. This also seems to be an issue with only libstdc++. Upgrading to a newer g++ fixes it (as long as you use that newer g++) as it appears newer versions of libstdc++ have this fixed.
updating to what? I'm on g++ 12.3.0 on my production machines, where the problem persists...? It's literally the latest available g++ on ubuntu 22.04.
The fix that @Mishura4 implemented doesn't seem to work. This also seems to be an issue with only libstdc++. Upgrading to a newer g++ fixes it (as long as you use that newer g++) as it appears newer versions of libstdc++ have this fixed.
Oh? Maybe upgrading isn't a fix then.
This issue has had no activity and is being marked as stale. If you still wish to continue with this issue please comment to reopen it.
Git commit reference 9c549f56feff00b13fc83193ce4aea6dc009058a
Describe the bug Sending messages, with files, causes a memory leak. The leak is bigger if the file is bigger.
The issue seems to be coming from:
and the queue itself.
The data doesn't actually get removed until the final request has been deleted from the queue.
if you're making frequent requests, the map will never empty, meaning the data is never freed (not sure why).
However, even when the queue is now empty, the ram doesn't fully recover. For example:
To Reproduce 1) Run the following code:
2) Watch the memory increase, then wait 120 seconds (for all 12 messages to clear) and watch the memory massively decrease.
Expected behavior The memory should slowly clear with every remove from the queue.
Ideally, we should use
unique_ptr
so we can avoid the 60 second queue sillyness.System Details: