The new version seems has Memory Leak issues!

Bug Reports
1
Issue Description

Multiple MEM_MAPPED regions with a total size exceeding 1.6 TB are observed in the process’s virtual address space, sharing the same AllocationBase 00007df55f590000 .

image
image793×664 46.6 KB

These regions alternate between PAGE_READONLY and PAGE_NOACCESS protections, with no associated files (confirmed via !vadump ).
image
image606×861 20.9 KB

Thread stacks show frequent calls to V8 compilation functions (e.g., v8::internal::compiler::CompilationDependencies ) and zlib functions (e.g., Cr_z_adler32 ).
image
image1142×851 43.5 KB

Analysis Steps
  1. !address -summary confirmed <unknown> memory dominates.
  2. !vadump showed all suspicious regions share the same AllocationBase without file associations.
  3. Thread stacks indicate memory operations are concentrated in V8 compilation and zlib data processing.
Hypotheses
  • Hypothesis 1: V8 JIT compilation leaks optimized code caches (e.g., Isolate/Context lifecycle issues).
  • Hypothesis 2: zlib compression/decompression fails to release temporary buffers (e.g., missing inflateEnd).
  • Hypothesis 3: Chromium’s shared memory mechanism (e.g., base::SharedMemory) leaves mapped regions unclosed.
2

Hi, which version number of Cursor are you referring to?

3

image
image355×264 4.44 KB

4

How about with 0.47.9

Cursor Settings > Beta > Update Frequency: Early Access

5

Still and I think this is a hidden problem. If you can provide PDB, I think we can have more detailed analysis

6

https://github.com/electron/electron/releases/download/v34.3.4/electron-v34.3.4-win32-x64-pdb.zip

7

Only electron’s pdb? I mean cursor’s own pdb :grinning_face:

8

Cursor does not use V8 or Chromium directly, only through electron.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.