[Bug?]: ZipFs not cached in Pnpm mode causing Couldn't allocate enough memory (not node but wasm memory)
#6722
Labels
bug
Something isn't working
Comments
|
Note: I noticed a bunch of other bugs reporting Out Of Memory errors. I have not had the bandwidth yet to confirm if they are affected by the same issue or not... |
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Self-service
Describe the bug
It seems that our repo is running into a race condition in the cache where it creates multiple ZipFs instances for the same downloaded .tgz file (same cachepath and same locator hash.
I could not repro with pnp mode but have in pnpm mode. We are not ready in all our tooling to handle pnp mode yet....
There is a parallelism phase for the 'link' phase which is great. Yet it seems in the cache it does have protection for a mutex, but the mutex is ONLY for the descriptor creation... I.e. it creates a single instance of the function that creates the ZipFs object.... since they ZipFs creation is still behind the
LazyFsimplementation there is still a chance that multipleZipFsinstances get created, which seems to be what is happening...In the repro steps below , I've described some added some logging lines and the output when run..
This clearly shows that the wasm memory is growing and growing to close to the 2Gb limmit.
This is simplified logging where I only report the calls to create ZipFS instances for a single large package, but there are many many packages that get more than one ZipFS Implementation.
I haven't fully wrapped my head around why this is but it seems due to transitive dependencies, where this package is layed out on disk as siblings in parallel...
The other aspect that seems to go wrong is the 'release' function in
I'd love to provide the fix for this. I'm filing this issue to help get early feedback what would be the preference.
Possible avenues:
LazyFs'sbaseFsfunction where it calls the factory.In my prototype I pursued the first option (1) and which consisted of 2 changes:
To reproduce
I've been trying to create a smaller repro but have not been successful wiht the OOM error. I've been trying to add dependencies on a large package like
ep_latexin the yarn repo itself and use pnpm mode but to no avail..The project that demonstrates this is an internal repo reliant on an internal feed with internal only packages that I can't share.. I have shared the particular details below. But if you want to see the problem in the yarn v4 repo itself I have created a branch that shows the issue:
https://github.com/dannyvv/yarn-berry/pull/new/repro/ShowDuplicateZipFsCreation
It shows that there are only a few packages that are created with duplicate ZipFs instances.. In our repo we reach a lot higher count for many packages. Note my devbox has 32-threads...
In my repro I made a few changes to Yarn:
In
cache.ts:const zipFsBuilder = shouldMock ? () => makeMockPackage() - : () => new ZipFS(cachePath, {baseFs, readOnly: true}); + : () => { + if (locator.name == "canvas-contextual") { + console.trace("new ZipFS for a large 168 Mb package" + cachePath + " with mutex locator hash: " + locator.locatorHash); + } + return new ZipFS(cachePath, {baseFs, readOnly: true}); + }in
libzipsync.js:function _emscripten_resize_heap(requestedSize) { + (requestedSize < 0 ? console.trace : console.error)("libzipSync:: _emscripten_resize_heap to " + requestedSize); var oldSize = HEAPU8.length;in
zipzipAsync.js:function _emscripten_resize_heap(requestedSize) { + (requestedSize < 0 ? console.trace : console.error)("libzipASync:: _emscripten_resize_heap to " + requestedSize); var oldSize = HEAPU8.length;Running on our repo that has that large package with tons of dependencies I get:
At this point in time we have pulled in 1.7GiB of packages.. And the node memory is already at ~3Gb.
No problem with this, we all have at least 32 thread machines with 64Gb machines...
The problem is the WASM limit of 2Gb. Downloading only has already asked it to grow to just 200Mb.
But as you'll see below it will soon balloon to over 2Gb and will be asked to grow to negative values...
The total of .tgz files is already close to the WebAssembly limmit:
Environment
System: OS: Windows 11 10.0.26100 CPU: (32) x64 AMD Ryzen Threadripper PRO 3955WX 16-Cores Binaries: Node: 22.13.0 - ~\AppData\Local\Temp\xfs-192a2d33\node.CMD Yarn: 4.7.0-git.20250305.hash-3c8a90ace - ~\AppData\Local\Temp\xfs-192a2d33\yarn.CMD npm: 10.9.2 - C:\Program Files\nodejs\npm.CMDAdditional context
No response
The text was updated successfully, but these errors were encountered: