-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak when resizing quickly #1857
Comments
Slowly but steadily growing OR shrinking in one direction (without waiting for reflow) seems to be the most reliable way to reproduce this. |
It also helps to have a high scrollback limit to make this more obvious. Mine's set to 1 GB. |
I tried the easy thing by replacing |
I cannot reproduce this. @kdrag0n, can you test again on the latest version and see if you still get this behavior? It's possible one of the recent changes fixed whatever was causing this. |
Hmm, I'm still seeing this on 7741463. |
Can you try this config and font (just in case it somehow matters)?
|
I can reproduce this with your config! I'll try to narrow down the exact cause. (My suspicion is that it could be related to |
Nevermind... now I can reproduce it without the config... either way I am working on debugging the problem now. |
Repro:
xxd /dev/zero
for a bit to fill the scrollback bufferUnlike #1853, this memory is released when the respective split/tab/surface is closed, but it's not released as long as the surface exists.
All the leaked memory is in raw
mmap
regions in this case (as shown byfootprint
), so I think it's caused by leaked Pages.Scrollback buffer should be large enough that reflow takes a noticeable amount of time.
Screenshot.2024-06-09.at.09.32.31.PM.mp4
The text was updated successfully, but these errors were encountered: