On a shared server my extension host went into a crash loop after 3.15.6 update. The diagnosis was that the extension host is now reserving >80+GB of VAS and I am hitting a user limit set in limits.d config of 96GB. Result is extension host crash. Logs:
thread ‘gix_status::index_as_worktree’ panicked at gix-features/src/parallel/in_parallel.rs:83:22:
valid name: Os { code: 11, kind: WouldBlock, message: “Resource temporarily unavailable” }
thread ‘gix::status::index_worktree::producer’ panicked at gix-status/…/mod.rs:333:86
thread ‘’ panicked at gix/src/status/iter/mod.rs:269:56
Rayon: detected unexpected panic; aborting
Extension Host Process exited with code: null, signal: SIGABRT.
The resolution was to set the following environment (eg in ~/.bashrc):
This is holding ext host VmPeak to around 75GB and now it’s not crashing for me.
Can someone at Cursor confirm this diagnosis and advise, should I ask my admin to increase VM limit because the extension host needs a lot of VAS. Even now with the above fix there is not much headroom.
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
This is a cursor session on remote host via ssh. Here are some details (after applying the above environment variable fix).
---- OS / kernel ----
os: Ubuntu 22.04.4 LTS
kernel: Linux 5.15.0-179-generic x86_64 GNU/Linux
libc: ldd (Ubuntu GLIBC 2.35-0ubuntu3.13) 2.35
-— CPU ----
cores(nproc):128 online=128
CPU(s): 128
Model name: Intel(R) Xeon(R) Gold 6338N CPU @ 2.20GHz
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 2
NUMA node(s): 2
-— Memory ----
total used free shared buff/cache available
Mem: 755Gi 57Gi 23Gi 33Mi 674Gi 693Gi
Swap: 0B 0B 0B
-— system limits.d (nproc / address-space caps) ----
/etc/security/limits.d/limit-ram.conf:6:* hard rss 100663296
/etc/security/limits.d/limit-ram.conf:7:* hard as 100663296
/etc/security/limits.d/limit-nproc.conf:10:* soft nproc 20000
/etc/security/limits.d/limit-nproc.conf:11:* hard nproc 20000
To reproduce, simply clone the workspace on the server and open the workspace in Cursor after connecting via ssh, with similar memory limit:
/etc/security/limits.d/limit-ram.conf:6:* hard rss 100663296
/etc/security/limits.d/limit-ram.conf:7:* hard as 100663296
The extension host crashes constantly which renders Cursor unusable.
Hey Barry, thanks for the detailed write-up. Your MALLOC_ARENA_MAX=2 + RAYON_NUM_THREADS=4 workaround is a solid short-term fix. For large shared remotes, also try turning off Index Repositories for Instant Grep in Cursor Settings (that’s the kill switch that usually stops this class of crash).
What you’re seeing isn’t caused by anything in your setup - we’ve let the team know and this is an issue we’re tracking. I’ll post here when there’s an update.