Memory leak

isorropisths commented

2026-11-09 09:18:48 +00:00

(Migrated from github.com)

Hookshot version

v2.0.7

What kind of problem

Crash, freeze or black screen

What happened

Built the game with v2.0.1 or v2.0.2, i'm not sure I remember, and I was having the psychedelic glitch on screen with 1fps, then turned the resolution to 50% and it fixed the glitch, but not the 1fps. The Title screen and video plays at 60fps, but as soon as you get in-game it's back to 1fps.

I then updated to v2.0.5, same. v2.0.7, same. I then decided to rebuild the game using v2.0.7, because all the other versions I was using the already-built folder. The game launches, and the colours are oversaturated, the video plays, and then post video the game stays at a blackscreen, and memory fast fills my 32GB RAM limit, causing the watchdog to kill it.

I've tried extracting the AppImage to run the bin/hookshot, and it's the same.

Where in the game

Post title screen video

How often

Every time

Graphics card and driver version

RX 5700XT, latest mesa

CPU, RAM and operating system

AMD 5700X3D, 32GB DDR4 3200, Fedora 44 GNOME 50

Changes from the defaults

No response

Other software hooked into the game

Hooked MangoHud, tried without, same.

hookshot_log.txt

Screenshots or video

No response

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.7 ### What kind of problem Crash, freeze or black screen ### What happened Built the game with v2.0.1 or v2.0.2, i'm not sure I remember, and I was having the psychedelic glitch on screen with 1fps, then turned the resolution to 50% and it fixed the glitch, but not the 1fps. The Title screen and video plays at 60fps, but as soon as you get in-game it's back to 1fps. I then updated to v2.0.5, same. v2.0.7, same. I then decided to rebuild the game using v2.0.7, because all the other versions I was using the already-built folder. The game launches, and the colours are oversaturated, the video plays, and then post video the game stays at a blackscreen, and memory fast fills my 32GB RAM limit, causing the watchdog to kill it. I've tried extracting the AppImage to run the bin/hookshot, and it's the same. ### Where in the game Post title screen video ### How often Every time ### Graphics card and driver version RX 5700XT, latest mesa ### CPU, RAM and operating system AMD 5700X3D, 32GB DDR4 3200, Fedora 44 GNOME 50 ### Changes from the defaults _No response_ ### Other software hooked into the game Hooked MangoHud, tried without, same. ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34571962/hookshot_log.txt) ### Screenshots or video _No response_ ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

NotRexed commented

2026-11-09 09:20:59 +00:00

(Migrated from github.com)

Thanks for the report. The RX 5700 XT has no mesh shaders, so it runs on the fallback path; linking this to that tracker #1001 (and the Linux tracker #1000). The RAM filling up after the title video on the v2.0.7 rebuild is the key detail.

isorropisths commented

2026-11-09 09:23:13 +00:00

(Migrated from github.com)

The RAM filling up I had it before too (v2.0.3) but updating to v2.0.5 (without rebuilding) stopped it. Playing on v2.0.7 without rebuilding also didn't fill up ram, only after rebuilding with v2.0.7 I saw the ram filling up again.

zhiying-326 commented

2026-11-09 12:11:40 +00:00

(Migrated from github.com)

Iris Xe on Linux (Mesa ANV), v2.0.7: the first mesh draw takes a SIGSEGV inside libvulkan_intel.so, and RSS climbs 5.7 -> 26 GB at that same frame.

Same shape as the report above (video plays, then black and RAM to the limit), on a different vendor and driver. Gen12.2 has no VK_EXT_mesh_shader either, so it is the fallback path.

Presentation Th[95709]: segfault at 4 ip 00007f3d52e1fa14 ... in libvulkan_intel.so[a1fa14,...]
vk: mesh draw kind 0: 0 2 1680, indirect 0 count 0 max 0 stride 0
vk: mesh draw: program 1f5f, 3 stages: [1: stage 6, ... isbe 1 payload 256] [2: stage 7, ...]

It is a small draw (2 task workgroups), so it does not look like a size problem. I also found that --prepare-shaders leaks on its own with no game, no window and nothing drawn: flat at 4.0 GB for 14 minutes, then 4.0 -> 18.7 GB in 6 minutes while @@progress stayed at 0.028.

Full report, with per-second memory samples and both backtraces, is in #1001: #1001

RX_VK_PRECOMPILE=0 gets past the preparation leak and gives a window and a full intro movie; it does not get past the crash at the first mesh draw.

**Iris Xe on Linux (Mesa ANV), v2.0.7: the first mesh draw takes a SIGSEGV inside `libvulkan_intel.so`, and RSS climbs 5.7 -> 26 GB at that same frame.** Same shape as the report above (video plays, then black and RAM to the limit), on a different vendor and driver. Gen12.2 has no `VK_EXT_mesh_shader` either, so it is the fallback path. ``` Presentation Th[95709]: segfault at 4 ip 00007f3d52e1fa14 ... in libvulkan_intel.so[a1fa14,...] vk: mesh draw kind 0: 0 2 1680, indirect 0 count 0 max 0 stride 0 vk: mesh draw: program 1f5f, 3 stages: [1: stage 6, ... isbe 1 payload 256] [2: stage 7, ...] ``` It is a small draw (2 task workgroups), so it does not look like a size problem. I also found that `--prepare-shaders` leaks on its own with no game, no window and nothing drawn: flat at 4.0 GB for 14 minutes, then 4.0 -> 18.7 GB in 6 minutes while `@@progress` stayed at 0.028. Full report, with per-second memory samples and both backtraces, is in #1001: https://git.magicbean.dev/MagicBeanDev/Hookshot/issues/1001 `RX_VK_PRECOMPILE=0` gets past the preparation leak and gives a window and a full intro movie; it does not get past the crash at the first mesh draw.

isorropisths commented

2026-11-09 13:12:49 +00:00

(Migrated from github.com)

v2.0.8rc3 increased the framerate to ~7fps, with the same memory leak.

TheAnnoyingFruit commented

2026-11-09 13:30:47 +00:00

(Migrated from github.com)

I don't believe the memory leak is just with this fallback because I have a 6700xt and it still fills my ram before the opening cutscene finishes.

isorropisths commented

2026-11-09 17:07:38 +00:00

(Migrated from github.com)

Is there a point testing this on a GPU without mesh shaders? or emulation is the peak for those GPUs?

NotRexed commented

2026-11-09 22:16:50 +00:00

(Migrated from github.com)

+1 from #1331 (closed into this): RX 5700, Mesa 26.2.5, Omarchy (Arch, Hyprland), v2.0.11: 8-10 fps from the first gameplay frame, and RAM grows to 32 of 40 GB.

zeeboguy commented

2026-11-10 02:38:28 +00:00

(Migrated from github.com)

Another data point, on NVIDIA. Unlike the AMD reports, fps is fine at first, but memory still keeps growing until the game freezes.

Setup: v2.0.11 native Linux AppImage build. Arch (Omarchy, Hyprland). RTX 5080 16 GB, NVIDIA 615.78.08. Kernel 7.2.15. 32 GB RAM.

What happens:

The game runs a steady 60 fps (fullscreen, 4K TV, 100% resolution).
Its RAM use keeps climbing. Once the system starts swapping, fps falls to 15-30, then the game freezes and has to be killed.
This happens even when staying in one area for the whole session, so it looks like a steady leak rather than new areas loading.

Session	Length	Peak RAM	Peak swap
1	74 min	18.7 GB	5.4 GB
2	34 min	18.0 GB	7.4 GB

(The peak numbers are from systemd's accounting of the game's scope.)

The game's own log counters stay roughly flat while RAM grows, so the growth seems to be somewhere the log doesn't report:

imports: about 2.0 to 2.7 GB live
mirrors: about 1.5 to 1.8 GB
captures kept: about 150 to 340 MB
textures: 2.5 to 5.5 GB, going up and down

Device-heap VRAM was near its budget at the end (11.7 of 12.5 GB used). Right before the freeze, the log shows a capture's wait for write-back ... timed out a few times.

I can share the full game.log if it helps.

Another data point, on NVIDIA. Unlike the AMD reports, fps is fine at first, but memory still keeps growing until the game freezes. **Setup:** v2.0.11 native Linux AppImage build. Arch (Omarchy, Hyprland). RTX 5080 16 GB, NVIDIA 615.78.08. Kernel 7.2.15. 32 GB RAM. **What happens:** - The game runs a steady 60 fps (fullscreen, 4K TV, 100% resolution). - Its RAM use keeps climbing. Once the system starts swapping, fps falls to 15-30, then the game freezes and has to be killed. - This happens even when **staying in one area for the whole session**, so it looks like a steady leak rather than new areas loading. | Session | Length | Peak RAM | Peak swap | |---|---|---|---| | 1 | 74 min | 18.7 GB | 5.4 GB | | 2 | 34 min | 18.0 GB | 7.4 GB | (The peak numbers are from systemd's accounting of the game's scope.) The game's own log counters stay roughly flat while RAM grows, so the growth seems to be somewhere the log doesn't report: - imports: about 2.0 to 2.7 GB live - mirrors: about 1.5 to 1.8 GB - captures kept: about 150 to 340 MB - textures: 2.5 to 5.5 GB, going up and down Device-heap VRAM was near its budget at the end (11.7 of 12.5 GB used). Right before the freeze, the log shows `a capture's wait for write-back ... timed out` a few times. I can share the full game.log if it helps.

juliocoliveira commented

2026-11-10 14:44:00 +00:00

(Migrated from github.com)

This memory leak is still happening on the latest version 2.0.13.

sonkite225 commented

2026-11-11 09:42:36 +00:00

(Migrated from github.com)

happens also on 2.1.0

isorropisths commented

2026-11-11 10:34:19 +00:00

(Migrated from github.com)

The latest release fixes my memory leak, the oversaturation, and the low fps.

lisasis commented

2026-11-11 12:14:17 +00:00

(Migrated from github.com)

The latest release fixes my memory leak, the oversaturation, and the low fps.

can you share your hookshot_options.ini still overcomsuming ram for me

> The latest release fixes my memory leak, the oversaturation, and the low fps. can you share your hookshot_options.ini still overcomsuming ram for me

mooki000 commented

2026-11-11 13:05:05 +00:00

(Migrated from github.com)

A 44-minute run on NVIDIA at 4K: no growth like the RTX 5080 report above, on current main. RTX 4090, NVIDIA 615.78.08, i9-13900K, 93 GB RAM, Arch Linux; main bdfe09c built from source; headless (no window), Output resolution 3840x2160, Render resolution 100%, 60 FPS cap.

Kokiri Forest from a save, with a camera turn every 9 s for 2,770 s (164,827 frames, 60 fps). The game's memory was sampled every 10 s from /proc and nvidia-smi:

minutes	2	12	22	32	42	46
RSS, MB	14427	14479	14512	14527	14544	14556
card memory, MB	10154	9642	10284	10668	10284	9452

That's +26 MB per 10 minutes, almost all of it in anonymous memory (+24 MB). Card memory stayed flat.
The log's own counters stayed flat too: imports 1,744 MB, mirrors 1.46-1.52 GB, shadows 368-384 MB, captures kept 139-217 MB, textures 4.0-4.5 GB.

So on this driver and current main, staying in one area doesn't fill RAM the way @zeeboguy saw on v2.0.11 (18-18.7 GB and swapping after 34-74 minutes). At this rate it would grow about 0.2 GB in 74 minutes.

I haven't tested v2.0.11 itself, other areas, a windowed or fullscreen run (the swapchain and the scaling to the screen are left out headless), longer than 44 minutes, or AMD.

**A 44-minute run on NVIDIA at 4K: no growth like the RTX 5080 report above, on current main.** RTX 4090, NVIDIA 615.78.08, i9-13900K, 93 GB RAM, Arch Linux; main bdfe09c built from source; headless (no window), Output resolution 3840x2160, Render resolution 100%, 60 FPS cap. Kokiri Forest from a save, with a camera turn every 9 s for 2,770 s (164,827 frames, 60 fps). The game's memory was sampled every 10 s from /proc and nvidia-smi: | minutes | 2 | 12 | 22 | 32 | 42 | 46 | |---|---|---|---|---|---|---| | RSS, MB | 14427 | 14479 | 14512 | 14527 | 14544 | 14556 | | card memory, MB | 10154 | 9642 | 10284 | 10668 | 10284 | 9452 | - That's +26 MB per 10 minutes, almost all of it in anonymous memory (+24 MB). Card memory stayed flat. - The log's own counters stayed flat too: imports 1,744 MB, mirrors 1.46-1.52 GB, shadows 368-384 MB, captures kept 139-217 MB, textures 4.0-4.5 GB. So on this driver and current main, staying in one area doesn't fill RAM the way @zeeboguy saw on v2.0.11 (18-18.7 GB and swapping after 34-74 minutes). At this rate it would grow about 0.2 GB in 74 minutes. I haven't tested v2.0.11 itself, other areas, a windowed or fullscreen run (the swapchain and the scaling to the screen are left out headless), longer than 44 minutes, or AMD.

juliocoliveira commented

2026-11-11 13:18:53 +00:00

(Migrated from github.com)

I retested in the latest version 2.1, and still is consuming over 14GBs, with my 32GB it consumed almost all ram, leaving 2GB on max left.
Would be great if this port got some optimization, 14GB is too much for a game.
I don't know if this is still considered a memory leak, but the ram consumption is great.

I retested in the latest version 2.1, and still is consuming over 14GBs, with my 32GB it consumed almost all ram, leaving 2GB on max left. Would be great if this port got some optimization, 14GB is too much for a game. I don't know if this is still considered a memory leak, but the ram consumption is great.

mooki000 commented

2026-11-11 16:26:52 +00:00

(Migrated from github.com)

What the ~14 GB are and what changes them, measured on Linux with an NVIDIA card. RTX 4090, NVIDIA 615.78.08, i9-13900K, 93 GB RAM, Arch Linux; main bdfe09c built from source (41 commits after v2.1.0), headless, 60 FPS cap, Kokiri Forest from a save with a camera turn every 9 s. Memory is read from /proc and nvidia-smi. These are memory counts, not frame rates: other jobs ran on the machine (load average 121 falling to 41 during the default run, 5 to 16 during the others).

At the default settings (Output resolution 2048x1152, Render resolution Auto), 220 s after the start:

	MB
resident, as a task manager shows it	14,354
the game's own memory	7,096
Hookshot's own	6,845

(They add up to 13,941 MB; the other 413 MB look like the NVIDIA driver's mappings counted twice.)

About half is the game itself. It's told it has 9,809 MB, as on the console, and had touched 7,096 MB of it by then.
Most of Hookshot's half is made before the title, by the start-up shader preparation. In a local build with log lines at its steps, the memory in use grew by 1,015 MB when the pipeline cache was given to the driver, by 2,197 MB for 23,641 shader modules and by 2,030 MB for 16,574 pipelines: 5,242 MB.
It stays in use and it's steady: not a leak here. In play the log says vk: malloc: 5914 MB in arenas (5703 MB in use, 210 MB free). Resident memory stayed between 14,271 and 14,418 MB from 60 s to the end, and in the 44-minute run above it grew 26 MB per 10 minutes.

What changes it, with the same save:

	read at	resident, MB	card, MiB
default	150 s	14,312	7,714
Render resolution 50%	110 s	14,411	7,314
a first start with the README's `RX_VK_LOW_SPEC=1` (the Minimum (4GB) preset)	110 s	14,388	7,332
without the shader preparation (`RX_VK_PRECOMPILE=0`, a developer switch)	140 s	10,457	7,130

No setting I measured lowers it, @lisasis. Render resolution 50% and the Minimum preset drew the 3D at 1024x576 and took less of the card, but RAM stayed the same. (The preset's Handheld profile takes a restart and its video memory caps didn't apply on a 24 GB card, so that run tested its lower Render resolution.) Higher settings don't raise it either: with Output resolution 3840x2160 and Render resolution 100% two runs were at 14,417 and 14,505 MB 80 s after the start, against 14,315 and 14,379 MB at the defaults.
Skipping the preparation lowers it by 3,855 MB, but that's a developer switch and I'm not suggesting it. The game's own part was unchanged. In that run 962 pipelines were built during play instead, and 10 of the log's 64 reports (one per 120 frames) show draws left out as not ready, up to 28.7 a frame. I didn't measure its stutter: the machine wasn't quiet, and this folder's caches were warm. Whether to change the preparation is for the maintainers.
@juliocoliveira: "over 14 GB" for the game matches what I see, but by itself it doesn't fill 32 GB. What does your task manager show for the hookshot process alone, and which GPU is it?

For the maintainers: the README's "A run uses about 10 GB" matches the run without the preparation; with it I see 14,354 MB. That run built 962 pipelines in 140 s, of the 16,574 the preparation makes ready. As I read gpu/vk, the shader modules are needed again only when a new pipeline is built, and on this prepared folder play built 3 in 220 s. Whether the driver gives the modules' 2,197 MB back when they're destroyed, I haven't measured.

Not tested: Windows, AMD, the v2.1.0 release build itself, other areas, a window or fullscreen, Profile Handheld, the presets on a card their caps apply to, frame times, sessions longer than the 44 minutes above.

**What the ~14 GB are and what changes them, measured on Linux with an NVIDIA card.** RTX 4090, NVIDIA 615.78.08, i9-13900K, 93 GB RAM, Arch Linux; main bdfe09c built from source (41 commits after v2.1.0), headless, 60 FPS cap, Kokiri Forest from a save with a camera turn every 9 s. Memory is read from /proc and nvidia-smi. These are memory counts, not frame rates: other jobs ran on the machine (load average 121 falling to 41 during the default run, 5 to 16 during the others). At the default settings (Output resolution 2048x1152, Render resolution Auto), 220 s after the start: | | MB | |---|---| | resident, as a task manager shows it | 14,354 | | the game's own memory | 7,096 | | Hookshot's own | 6,845 | (They add up to 13,941 MB; the other 413 MB look like the NVIDIA driver's mappings counted twice.) - **About half is the game itself.** It's told it has 9,809 MB, as on the console, and had touched 7,096 MB of it by then. - **Most of Hookshot's half is made before the title, by the start-up shader preparation.** In a local build with log lines at its steps, the memory in use grew by 1,015 MB when the pipeline cache was given to the driver, by 2,197 MB for 23,641 shader modules and by 2,030 MB for 16,574 pipelines: 5,242 MB. - **It stays in use and it's steady: not a leak here.** In play the log says `vk: malloc: 5914 MB in arenas (5703 MB in use, 210 MB free)`. Resident memory stayed between 14,271 and 14,418 MB from 60 s to the end, and in the 44-minute run above it grew 26 MB per 10 minutes. What changes it, with the same save: | | read at | resident, MB | card, MiB | |---|---|---|---| | default | 150 s | 14,312 | 7,714 | | Render resolution 50% | 110 s | 14,411 | 7,314 | | a first start with the README's `RX_VK_LOW_SPEC=1` (the Minimum (4GB) preset) | 110 s | 14,388 | 7,332 | | without the shader preparation (`RX_VK_PRECOMPILE=0`, a developer switch) | 140 s | 10,457 | 7,130 | - **No setting I measured lowers it, @lisasis.** Render resolution 50% and the Minimum preset drew the 3D at 1024x576 and took less of the card, but RAM stayed the same. (The preset's Handheld profile takes a restart and its video memory caps didn't apply on a 24 GB card, so that run tested its lower Render resolution.) Higher settings don't raise it either: with Output resolution 3840x2160 and Render resolution 100% two runs were at 14,417 and 14,505 MB 80 s after the start, against 14,315 and 14,379 MB at the defaults. - **Skipping the preparation lowers it by 3,855 MB, but that's a developer switch and I'm not suggesting it.** The game's own part was unchanged. In that run 962 pipelines were built during play instead, and 10 of the log's 64 reports (one per 120 frames) show draws left out as not ready, up to 28.7 a frame. I didn't measure its stutter: the machine wasn't quiet, and this folder's caches were warm. Whether to change the preparation is for the maintainers. - @juliocoliveira: "over 14 GB" for the game matches what I see, but by itself it doesn't fill 32 GB. What does your task manager show for the hookshot process alone, and which GPU is it? For the maintainers: the README's "A run uses about 10 GB" matches the run without the preparation; with it I see 14,354 MB. That run built 962 pipelines in 140 s, of the 16,574 the preparation makes ready. As I read `gpu/vk`, the shader modules are needed again only when a new pipeline is built, and on this prepared folder play built 3 in 220 s. Whether the driver gives the modules' 2,197 MB back when they're destroyed, I haven't measured. Not tested: Windows, AMD, the v2.1.0 release build itself, other areas, a window or fullscreen, Profile Handheld, the presets on a card their caps apply to, frame times, sessions longer than the 44 minutes above.

ItsWoka commented

2026-11-11 20:47:36 +00:00

(Migrated from github.com)

Memory leaks in 2.1.0
ryzen 5-5600
3060 ti
16gb ddr4
linux mint

Logs:

hookshot_log.1.txt
hookshot_log.txt

Memory leaks in 2.1.0 ryzen 5-5600 3060 ti 16gb ddr4 linux mint <img width="778" height="101" alt="image" src="https://github.com/user-attachments/assets/c579c685-6224-468d-887c-d963c8a30745" /> <img width="354" height="56" alt="2026-11-11_16-45" src="https://github.com/user-attachments/assets/e6f7ee18-b2af-499e-abd9-202debafc5a1" /> Logs: [hookshot_log.1.txt](https://github.com/user-attachments/files/34706470/hookshot_log.1.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34706471/hookshot_log.txt)

NotRexed commented

2026-11-11 21:22:08 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #993, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #993 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.