Memory leak when switching between chats.

[MeanEYE]

System:

• Nheko 0.6.1
• Installation method: Main repository
• Operating System: Debian Testing
• Desktop Environment: Gnome Shell (Wayland)

Actual behavior

Switching between chats constantly eats memory.

Expected behavior

Not eating memory.

Steps to reproduce

Switch between two chats for a while.

[MeanEYE]

I do realize this is an old version, before this project existed, but reporting on old repository will not result in any fixes and since the code base for the most part is the same, I thought this might be relevant.

[redsky17]

Are you noticing this when switching back and forth from the same two chats, or when switching between various other chats? nheko has some built-in caching of messages to prevent the need to re-request them from the server all the time. I just want to verify what you mean by the 'Switch between two chats for a while' portion of the issue.

[MeanEYE]

I tested with same two chats as that way it's easier to replicate the behavior and can't be attributed to just loading new history into memory.

Example before test, with both top chats loaded once:

After switching between the top two chats 10+ times:

[MeanEYE]

Please note that here difference is not as drastic as in some previous cases I ran into this issues. This might be something to do with the fact I restarted application before testing so that other chats don't affect the outcome.

If the application has longer uptime, I think results should be more drastic. However I don't have images of this, but I can test for that if you wish.

[redsky17]

Is there any chance you can run valgrind on nheko while you're doing this, and share the output file with me? I did this on my end, but wasn't able to see any memory leaks after a few minutes of switching back and forth.

This command should be sufficient:

valgrind --leak-check=full --show-leak-kinds=all /path/to/nheko

Nheko does run much slower under valgrind, just as an fyi.

If you can't run valgrind, let me know.

[MeanEYE]

nheko-report.txt

Here it is.

[deepbluev7]

I think this shouldn't be an issue anymore, since before we used widgets for the timeline, that were never freed. Now we use qml to dynamically generate the timeline view, which uses a bit of memory for caches, but should have an upper limit (apart from all the messages still being kept in memory, as we don't drop them from the in memory cache. That overhead should be reasonably minimal and should go away, once we actually use a proper disk cache for all messages in the future.)