# H Company — VRAM Ghost Busting: Who You Gonna `close()`?

- Company: H Company (hcompany.ai)
- Announced: 2026-06-25
- Category: not stated
- Coverage: not counted
- Announcement: no
- Group: routine
- Source: https://hcompany.ai/newsroom/vram-ghost-busting-who-you-gonna-close
- Record: https://forck.live/items/18366-vram-ghost-busting-who-you-gonna-close
- Subject: Holo

H Company engineers investigated GPU memory leaks on Kubernetes nodes where VRAM appeared allocated without an owning process. They traced the issue to containers that remained in RUNNING state after pod deletion, with threads stuck in D-state inside the FUSE kernel driver (`request_wait_answer`), blocking on a FUSE reply that never arrived. The post documents the debugging methodology and identifies the root cause as a FUSE mount hang rather than a CUDA or NCCL issue.

## Evidence

Verbatim from https://hcompany.ai/newsroom/vram-ghost-busting-who-you-gonna-close:

> Every single D-state thread was sleeping inside the same kernel function: request_wait_answer . That symbol is defined in `fs/fuse/dev.c` , i.e. the FUSE device driver. It is the function that parks a thread until the userspace FUSE daemon answers a request (more details about FUSE below). None of this was CUDA, NCCL, or similar: every stuck worker was blocked on a FUSE reply that never arrived.

---

Record: https://forck.live/items/18366-vram-ghost-busting-who-you-gonna-close
Catalogue: https://forck.live/llms.txt
Current issue: https://forck.live/feed.md