jan kili (Apr 04 2025 at 17:39): jan kili (Apr 04 2025 at 17:39):(follow-up on https://roc.zulipchat.com/#narrow/channel/306878-off-topic/topic/casual.20conversation/near/509760742)
@Anton Today I caught it on my system monitor - no CPU hogging, but maxed out my memory - Helix :lsp-stop freed 10GB :yum:
Anton (Apr 04 2025 at 17:39):Oh interesting, I'll see if I can reproduce
jan kili (Apr 04 2025 at 17:39):I'll move us to a debugging topic then
Notification Bot (Apr 04 2025 at 17:40):3 messages were moved here from #off topic > casual conversation by JanCVanB.
jan kili (Apr 04 2025 at 17:42):Yesterday I ran apt update/upgrade and updated Roc alpha3 from early March to late March
Anton (Apr 04 2025 at 17:49):Yeah, I can reproduce it, single letter edits cause 20-40 MiB jumps that never get cleaned up.
jan kili (Apr 04 2025 at 17:51)::orange_heart:
Anton (Apr 04 2025 at 17:54):#7727 I'll do some digging tomorrow
jan kili (Apr 04 2025 at 17:54):Thank you! It's not a blocker for me :)
Anton (Apr 04 2025 at 18:02)::+1: still a serious issue though
Anton (Apr 05 2025 at 18:21):I haven't gotten far yet, I'm struggling to get good traces (with mem allocation info). Currently I have:
@bytes[
78d56ecad650 __libc_malloc+0 (/usr/lib/x86_64-linux-gnu/libc.so.6)
5b99ddbd06f5 crossbeam_channel::channel::bounded::h00081419fd333688+245 (/home/username/gitrepos/roc3/roc/target/debug/roc_language_server)
5b99ddb519e5 roc_load_internal::file::load_single_threaded::h72d2df977ee96e5e+597 (/home/username/gitrepos/roc3/roc/target/debug/roc_language_server)
5b99ddb34ae7 roc_load::load_single_threaded::h91b57ea8a7617560+487 (/home/username/gitrepos/roc3/roc/target/debug/roc_language_server)
78d56ed29c3c __clone3+44 (/usr/lib/x86_64-linux-gnu/libc.so.6)
]: 8503296
I've been using bpftrace, do you have any recommendations @Brendan Hansknecht?
Brendan Hansknecht (Apr 05 2025 at 19:12):Anton said:
Yeah, I can reproduce it, single letter edits cause 20-40 MiB jumps that never get cleaned up.
@Joshua Warner suggested earlier that he thinks the old parser likely has memory leaks. I would guess the s is what you are seeing. Though 40MiB sounds like a lot. We might just be keeping arenas alive and making new asts instead of dumping the old arena before making a new ast.
Brendan Hansknecht (Apr 05 2025 at 19:13):And no suggests past use valgrind if possible. With all its tracking flags, it can give a ton of info.
Anthony Bullard (Apr 05 2025 at 19:47):At least we won’t have to worry about that with the new parser!
Anton (Apr 09 2025 at 13:21):valgrind --leak-check=full --track-origins=yes ... is clean, so I'm going to check the arenas now.
Anton (Apr 09 2025 at 18:03):heaptrack is a nice tool for this :)
When trying out some changes I've managed to make the problem worse (increased memory usage) :p this may help me find the cause though :fingers_crossed:
Brendan Hansknecht (Apr 09 2025 at 18:08):Heaptrack and Massif are both great (and in the new compiler Tracy)
Anton (Apr 11 2025 at 18:07):I suspect the problem may come from crates/language_server/src/registry.rs:update_document, that function has a lot of shady vibes :p in the sense that it may be keeping references alive too long. I'll give this one more day of investigating tomorrow.
Anton (Apr 12 2025 at 18:15):When I keep repeating the same two edits (in the Roc code) the memory gains are very inconsistent, sometimes very small (as they should be), sometimes ~30 MiB. I can't explain that given everything I've learned about this issue, I'm calling it quits :white_flag:
Nathan Kamenchu (May 14 2025 at 14:38):I've also experienced this issue where the memory allocated by the lsp slowly grows and I have to kill and restart it. Happens over a period of 30 or so minutes
Last updated: Jul 06 2025 at 12:14 UTC