Memory leak?

eschnett commented

2026-03-03 08:56:02 -08:00

(Migrated from github.com)

I tried Tachikoma on a MacBook Pro, using WezTerm as terminal, on Julia 1.12. When I run

julia --project=@. demos/test_sixel_diag.jl

then memory usage increases linearly with time at a rate of about 300 MByte/sec. (This crashes the system after a few minutes.)

(This demo only outputs a line at the bottom. I assume that there should be other things displayed as well, e.g. a gradient, but that doesn't seem to work. I tried basic sixel output, and that works. I don't know whether this sixel problem is related, it's probably not, but I wanted to mention it anyway.)

I tried to find out how this memory is used but I was unsuccessful. It's not the julia process (its memory usage remains constant) nor the WezTerm process (also constant memory usage). However, the system's total "memory usage" is climbing, and pages are being written into swap. The memory is also freed when I quit the demo.

I'd be happy to help debug this. I don't know where to start.

I tried Tachikoma on a MacBook Pro, using WezTerm as terminal, on Julia 1.12. When I run ``` julia --project=@. demos/test_sixel_diag.jl ``` then memory usage increases linearly with time at a rate of about 300 MByte/sec. (This crashes the system after a few minutes.) (This demo only outputs a line at the bottom. I assume that there should be other things displayed as well, e.g. a gradient, but that doesn't seem to work. I tried basic sixel output, and that works. I don't know whether this sixel problem is related, it's probably not, but I wanted to mention it anyway.) I tried to find out how this memory is used but I was unsuccessful. It's not the julia process (its memory usage remains constant) nor the WezTerm process (also constant memory usage). However, the system's total "memory usage" is climbing, and pages are being written into swap. The memory is also freed when I quit the demo. I'd be happy to help debug this. I don't know where to start.

kahliburke commented

2026-03-03 09:45:25 -08:00

(Migrated from github.com)

I have not used wezterm, just iterm2 and kitty. It might be related? Those demos are using the pixel graphics support, which is a bit more advanced and pushing the boundaries of what terminals are supposed to do ... this is a demo I've been working on :)

I have not used wezterm, just iterm2 and kitty. It might be related? Those demos are using the pixel graphics support, which is a bit more advanced and pushing the boundaries of what terminals are supposed to do ... this is a demo I've been working on :) <img width="731" height="680" alt="Image" src="https://github.com/user-attachments/assets/d78b7938-7871-48b1-a27a-f5e0a7c048b9" />

kahliburke commented

2026-03-03 10:24:16 -08:00

(Migrated from github.com)

I downloaded WezTerm and I did experience some issue with it, it doesn't seem to detect the graphics type automatically. If you set the environment variable:

export TACHIKOMA_GFX=sixel

You should get output then. Not sure if that fixes the memory leak. These 'demos' should actually be in the test directory so I'll move them there. There are some scripts there which I had used to debug some issues when testing with ITerm, kitty, and apple terminal. I haven't tested all the variations out there.

Let me know what your findings are?

I downloaded WezTerm and I did experience some issue with it, it doesn't seem to detect the graphics type automatically. If you set the environment variable: `export TACHIKOMA_GFX=sixel` You should get output then. Not sure if that fixes the memory leak. These 'demos' should actually be in the test directory so I'll move them there. There are some scripts there which I had used to debug some issues when testing with ITerm, kitty, and apple terminal. I haven't tested all the variations out there. Let me know what your findings are?

eschnett commented

2026-03-03 10:24:24 -08:00

(Migrated from github.com)

I have the suspicion that the two problems are related. The shared memory communication between Tachikoma and WezTerm might not be working. In this case, (a) WezTerm would not display anything, and (b) Tachikoma would continuously produce shared memory segments that are not deallocated.

Note that macOS has no way to list the shared memory segments that exist on the system (!). It is thus not possible to clean up in this case.

It might be better to use shared memory differently, without creating a large number of segments. Maybe a small number of segments (2?) could be created and reused in a circular way?

Or, as a work-around, Tachikoma could delete old (older than one second?) shared memory segments, as well as all shared memory segments when it quits.

I have the suspicion that the two problems are related. The shared memory communication between Tachikoma and WezTerm might not be working. In this case, (a) WezTerm would not display anything, and (b) Tachikoma would continuously produce shared memory segments that are not deallocated. Note that macOS has no way to list the shared memory segments that exist on the system (!). It is thus not possible to clean up in this case. It might be better to use shared memory differently, without creating a large number of segments. Maybe a small number of segments (2?) could be created and reused in a circular way? Or, as a work-around, Tachikoma could delete old (older than one second?) shared memory segments, as well as all shared memory segments when it quits.

kahliburke commented

2026-03-03 10:28:13 -08:00

(Migrated from github.com)

It's quite possible. It's something I could look into when I have time, or feel free to see what you can do with it and submit a PR. I thought I had at one point tried schemes like what you propose, but this went through a few iterations trying to get it working for both iterm and kitty at the same time. My thought is that it's the kitty protocol that is being used but unsuccessfully that is the issue, and that if you set it to sixel you would not have the problem. It's also likely that some better detection would prevent it from trying to use the kitty mode.

eschnett commented

2026-03-03 10:40:45 -08:00

(Migrated from github.com)

It seems that the "kitty shared memory detection" only checks whether shared memory is supported, not whether kitty can handle (and unlink) shared memory segments. Yes, this can be improved.

kahliburke commented

2026-03-03 10:49:00 -08:00

(Migrated from github.com)

I'll have a commit soon which should limit the max memory that could be leaked and also do a better job of preventing the leak.

eschnett commented

2026-03-03 11:05:50 -08:00

(Migrated from github.com)

(I wrote a Python script that tried all /tach_k* prefixes, and it found all the unused shared memory segments. I'm happy that I didn't have to reboot my computer again!)

(I wrote a Python script that tried all `/tach_k*` prefixes, and it found all the unused shared memory segments. I'm happy that I didn't have to reboot my computer again!)

kahliburke commented

2026-03-03 11:18:39 -08:00

(Migrated from github.com)

That's funny I'm about to commit a Julia script that does the same thing. :)

kahliburke commented

2026-03-03 11:33:45 -08:00

(Migrated from github.com)

Pushed a fix to fix/6-kitty-shm-leak. Segments are now tracked and unlinked by the sender after each frame, with cleanup on exit and atexit as a safety net.

Added test/cleanup_shm.jl to clean up leaked segments, and test/test_kitty_shm_stress.jl to stress test.

WezTerm sets TERM_PROGRAM=WezTerm so we can improve detection to skip the Kitty shm path entirely — will add that as a follow-up.

@eschnett if you get a chance:

julia --project test/cleanup_shm.jl to clean up any leftover segments
julia --project test/test_kitty_shm_stress.jl 1000 to verify the fix

Pushed a fix to `fix/6-kitty-shm-leak`. Segments are now tracked and unlinked by the sender after each frame, with cleanup on exit and atexit as a safety net. Added `test/cleanup_shm.jl` to clean up leaked segments, and `test/test_kitty_shm_stress.jl` to stress test. WezTerm sets `TERM_PROGRAM=WezTerm` so we can improve detection to skip the Kitty shm path entirely — will add that as a follow-up. @eschnett if you get a chance: - `julia --project test/cleanup_shm.jl` to clean up any leftover segments - `julia --project test/test_kitty_shm_stress.jl 1000` to verify the fix

Rows
Columns

Memory leak? #6