Memory leak

[ppyl-datBoi]

Vue version

3.5.4

Link to minimal reproduction

http://cant.insert.code/commercial_project

Steps to reproduce

The problem started to appear in Vue 3.5.* (including version 3.5.4). There are no problems in version 3.4.38.
In my case, the approximate source of the problem is an active websocket connection.

What is expected?

No memory leak

What is actually happening?

After establishing a socket connection from which data is coming, the memory grows infinitely. Moreover, the more socket connections, the more the memory grows without stopping. With 10 connections in 5-10 minutes, the heap size consumption is more than 3 GB.
An example of how a leak starts after the application starts:

At the same time, taking memory snapshots is very difficult because the snapshot formation often gets stuck at the stage (Building dominator tree).

If you still manage to take a memory snapshot, it turns out that the preliminary cause is deps (I may be wrong).

I want to clarify that in case of a leak:
DOM Nodes - do not change.
JS Event Listeners - do not change.

System Info

System:
    OS: Windows 10 10.0.19044
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i5-12400
    Memory: 13.66 GB / 31.77 GB
  Binaries:
    Node: 18.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  Electron": 32.0.1
  Browsers:
    Chrome: 128.0.6613.120
  npmPackages:
    vue: ^3.5.4 => 3.5.4

Any additional comments?

No response

[ppyl-datBoi]

Solution: After I removed {deep: true} in all "watch" functions the problem disappeared.
But because of the many such "watch " now I will have to reconsider the logic in the application.

[jh-leong]

Could you please check the reproduction link? It seems to be inaccessible.

[ppyl-datBoi]

I can't provide full repro code because I have a complex commercial project from which it is difficult to extract repro code. The fact is that "watch" with {deep: true} starts to leak.

[ppyl-datBoi]

I also noticed that it's not just watch that's leaking. I have a couple of computed functions that are also leaking (the events array is updated several times per second). I compared several snapshots and noticed that the deps class is not being cleared, and that's a problem on your end.

Example of comparing snapshots 3 minutes apart:

[edison1105]

We can't analyze the bug without a runnable minimal reproduction.
Please follow the issue requirement.

[ppyl-datBoi]

I don't know if this mini demo is what you wanted to see, but even from it you can see that when comparing memory snapshots, the Dep class is not cleared by GC.
But the computed leak could not be confirmed.
Here is the link

[edison1105]

Still unable to reproduce

• in Chrome incognito mode, ensure there are no browser extensions
• manually collect garbage
• JS heap size, DOM Nodes, JS event listeners. Their numbers will not continue to grow.

[gkubisa]

I'm not sure if it is related but when debugging a reactivity issue in one of my vitest tests I noticed an issue with the double-linked list for tracking dependencies:

• when traversing the list starting from depsTail using prevDep, there are 6 dependencies (not expected)
• when traversing the list starting from deps using nextDep, there are 2 dependencies (expected)

I wonder if a memory leak could be caused by the redundant Dep objects referenced by depsTail.prevDep.prevDep.prevDep.*? Maybe in some situations they could be accumulating much more than in my test code?

Unfortunately I'm still struggling to isolate the issue. :-/

PS. The issue I'm debugging is about a computed not registering as a dependency of a shallowRef, even though I can see that the track function is called by Vue as expected.

[ppyl-datBoi]

Still unable to reproduce

• in Chrome incognito mode, ensure there are no browser extensions
• manually collect garbage
• JS heap size, DOM Nodes, JS event listeners. Their numbers will not continue to grow.

I also deliberately launched the demo in incognito mode. As you can see from the screenshot, the memory is gradually growing from snapshot to snapshot. Deps is also growing and is not cleared. Even deliberately calling the garbage collector from devtools does not improve the situation.