8000 Z_BUF_ERROR - unexpected end of file · Issue #600 · pnpm/pnpm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Z_BUF_ERROR - unexpected end of file #600

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
vjpr opened this issue Feb 3, 2017 · 32 comments
Closed

Z_BUF_ERROR - unexpected end of file #600

vjpr opened this issue Feb 3, 2017 · 32 comments
Assignees
@zkochan

Comments

@vjpr
Copy link
Contributor
vjpr commented Feb 3, 2017

When I ran pnpm i I got this error. Then I re-ran it and i didn't get the error. Just looking to know if this could be a pnpm error?

Reproducing would be very difficult.

pnpm version:

0.51.1

Code to reproduce the issue:

Actual behavior:

/registry.npmjs.org/lodash/4.11.2/stage/package/fp"
  30338 error pnpm:
    err:
      name: "Error"
      message: "unexpected end of file"
      code: "Z_BUF_ERROR"
      stack: "Error: unexpected end of file\n    at Zlib._handle.onerror (zlib.js:370:17)\n"

Additional information:

  • node -v prints: 6.5.0
  • Windows, OS X, or Linux?: macOS
@zkochan
Copy link
Member
zkochan commented Feb 3, 2017 via email •
edited
Loading

@vjpr
Copy link
Contributor Author
vjpr commented Feb 3, 2017

Yep this is a project with 200+ deps.

@zkochan
Copy link
Member
zkochan commented Feb 3, 2017

Seems like this is because too many packages are being unpacked simultaneously. I added a limit fetch concurrency and it doesn't happen anymore. A PR will be ready today

@zkochan zkochan self-assigned this Feb 3, 2017
@zkochan zkochan mentioned this issue Feb 3, 2017
Closed
zkochan added a commit that referenced this issue Feb 3, 2017
@zkochan
fix(fetch): limit simultaneous fetches
32965be 
Rel #600, Rel #594
@zkochan zkochan mentioned this issue Feb 3, 2017
Merged
zkochan added a commit that referenced this issue Feb 3, 2017
@zkochan
fix(fetch): limit simultaneous fetches
7e7ef52 
Rel #600, Rel #594
@zkochan
Copy link
Member
zkochan commented Feb 5, 2017

I believe this is fixed in 0.52.1. I cannot reproduce this anymore

@vjpr
Copy link
Contributor Author
vjpr commented Feb 8, 2017 •
edited
Loading

I experienced this again with 0.53.0 on Windows. Re-running once worked. Is there a configuration option for this. --limit-fetch?

@zkochan
Copy link
Member
zkochan commented Feb 8, 2017

Currently hardcoded to 16 https://github.com/pnpm/pnpm/blob/master/src/api/install.ts#L213

@vjpr
Copy link
Contributor Author
vjpr commented Feb 8, 2017

Okay, I think it should be configurable if its still causing issues. I will see if I can reliably reproduce it and which value fixes it.

@zkochan
Copy link
Member
zkochan commented Feb 8, 2017

ok, I'll make it configurable. Concurrency is a real big issue.

zkochan added a commit that referenced this issue Feb 8, 2017
@zkochan
feat: make fetching concurrency configurable
6792b57 
And reduce the default value to 4

Ref #600
@zkochan
Copy link
Member
zkochan commented Feb 9, 2017

I reduced the concurrency to 4 in version 0.54.0 and you can set the value via the fetching-concurrency config

zkochan added a commit that referenced this issue Feb 26, 2017
@zkochan
feat: save tarballs before unpacking
df255d2 
...and unpack tarballs one by one

Close #600
@zkochan zkochan mentioned this issue Feb 26, 2017
Merged
@zkochan
Copy link
Member
zkochan commented Feb 28, 2017 •
edited
Loading

Fixed in v0.58.0.

@vjpr
Copy link
Contributor Author
vjpr commented Aug 14, 2017 •
edited
Loading

I just saw this error again in pnpm@1.10.2 and node@8.1.2.

There is also no indication of the package that caused it...

  25328 error pnpm:
    message:
      errno: -5
      code: "Z_BUF_ERROR"
    err:
      name: "Error"
      message: "unexpected end of file"
      code: "Z_BUF_ERROR"
      stack: "Error: unexpected end of file\n    at Gunzip.zlibOnError (zlib.js:152:15)"

Also tried with: pnpm i --fetching-concurrency=1

Is this the line where the extraction happens: https://github.com/zkochan/unpack-stream/blob/master/src/index.ts#L96

@zkochan
Copy link
Member
zkochan commented Aug 14, 2017 •
edited
Loading

Is this the line where the extraction happens: https://github.com/zkochan/unpack-stream/blob/master/src/index.ts#L96

yes

as far as I remember our initial idea was that it was caused by concurrency. I think --fetching-concurrency doesn't currently cover all the cases when unpacking happens. Unpacking from a local tarball is not limited (here's the function that unpacks local tars: https://github.com/pnpm/package-store/blob/master/src/fetchResolution.ts#L113)

@vjpr
Copy link
Contributor Author
vjpr commented Aug 15, 2017 •
edited
Loading

So it seems the package that was failing was material-design-icons, same that was causing EINTEGRITY errors in #872.

  25226 error pnpm:
    message:
      e:
        errno: -5
        code: "Z_BUF_ERROR"
      dest: "/home/vagrant/.pnpm-store/2/registry.npmjs.org/material-design-icons/3.0.1_stage"
      opts: {}
    e:
      errno: -5
      code: "Z_BUF_ERROR"
    dest: "/home/vagrant/.pnpm-store/2/registry.npmjs.org/material-design-icons/3.0.1_stage"
    opts: {}

So it seems the tar for material-design-icons that was published to npm is corrupt...

vagrant@intranav-app-vm:~/.pnpm-store/2/registry.npmjs.org/material-design-icons/3.0.1$ tar xzf packed.tgz

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

I think the only thing we need to do is show the file the failed to unzip, and tell the user to file a bug with the module.

Actually, it works fine if I download the tar manually...

wget https://registry.npmjs.org/material-design-icons/-/material-design-icons-3.0.1.tgz
tar xzf material-design-icons-3.0.1.tgz
// no problem

Copy packed.tgz to macOS from Ubuntu 16...

scp -P2222 vagrant@localhost:/home/vagrant/.pnpm-store/2/registry.npmjs.org/material-design-icons/3.0.1/packed.tgz .
tar xzf packed.tgz
tar: (Empty error message)
tar: Error exit delayed from previous errors.

gunzip packed.tgz
gunzip: packed.tgz: unexpected end of file
gunzip: packed.tgz: uncompress failed

The corruption must happen in package-store/src/network/got.ts#download. But the strange thing is that it happened to other people not using pnpm.

Ah so the downloader is configurable here: pnpm/src/network/got.ts#download.

Okay so it must be a bug in npm-registry-client then. At least I got to know the codebase a bit better.

Looks like the sizes are different:

// macOS
-rw-r--r--  1 Vaughan  staff  32990579 15 Aug 23:40 packed.tgz

// Ubuntu 16 / pnpm
-rw-rw-r--  1 vagrant vagrant 18497161 Aug 14 18:34 packed.tgz

So on Ubuntu 16 there is a partial download happening. I started getting EMFILE too many files open errors too sporadically. Maybe related.

@vjpr
Copy link
Contributor Author
vjpr commented Nov 16, 2017

I'm still seeing this error. Do you know if there was any progress on this being fixed. I think I remember that we need retry logic for packages that don't match their content length.

@mnzaki
Copy link
Contributor
mnzaki commented Jan 20, 2018

Can confirm also still seeing this. Hack to overcome issue:

node --inspect=0.0.0.0:9229 /usr/bin/pnpm i

Then open chrome node inspector => Sources tab => Enable Pause on Exceptions
Wait for Z_BUF_ERROR exception. Look at Scope data in debugger, dig down a few closures till you find the pkgname somewhere. Note the pkgname, press F8 (debugger 'continue'), wait for more exceptions and note more packages, until pnpm exits.

Now go to ~/.pnpm-store/ and rm -rf the package folders you noted. Run pnpm again and rinse and repeat.

My very first few hours of using pnpm was hunting this down as it made all installations fail. The culprit is that the first time I used it was installing 1.4k packages on a bad WiFi connection. Some downloads failed: a few random packages but also particularly something that was downloading prebuilt binaries.

I think a fairly simple solution is to at least just log the packages that failed in this run, and more advanced would be prompt the user to retry the failed packages.

All in all though, the grey hairs were worth the ~5GB of precious /home space I saved just converting around 10 node_modules to pnpm. Can't wait to get r 8000 id of the rest.

@zkochan
Copy link
Member
zkochan commented Jan 20, 2018

@mnzaki thanks for this thorough investigation!

As far as I understand, the tarball is downloaded correctly. Otherwise, integrity check would fail and pnpm re-downloads the package in that case. If that is the case, we can put the unpack logic into a try/catch and retry unpacking on this error.

@zkochan
Copy link
Member
zkochan commented Jan 20, 2018

Here's where we unpack the tarballs https://github.com/zkochan/unpack-stream/blob/master/src/index.ts#L88

@mnzaki
Copy link
Contributor
mnzaki commented Jan 20, 2018 •
edited
Loading

I tried to reproduce the error today, and did some more digging across async calls, this seems to be the problematic code: https://github.com/pnpm/tarball-fetcher/blob/master/src/index.ts#L134

async function fetchFromRemoteTarball (
// ...
) {
  try {
    const index = await fetchFromLocalTarball(unpackTo, opts.cachedTarballLocation)
    return index
  } catch (err) {
    if (err.code !== 'ENOENT') throw err
// ...
}

The problem is execution gets to this point even though the packed.tgz file is clearly corrupted. It tries to fetchFromLocalTarba 8000 ll which throws the Z_BUF_ERROR which gets rethrown in the catch block (since it's not ENOENT)

To reproduce:

  1. start installing something that has native bindings, I was testing with the package sodium-native
    I'm unsure if this is necessary for the bug, but I do know it is sufficient.
  2. Once it downloads a bit interrupt it. There will be a partial download packed.tgz.NNNNNNNNN file in the .pnpm-store. Rename this to packed.tgz (see note below)
  3. Run the installation again, debug it while failing with Z_BUF_ERROR

Note about corrupt files:

  1. I was unable to get pnpm to the point where it renames a corrupted file to packed.tgz by itself. But that is the condition I saw in my first attempts (I didn't manually rename a partial download of course....). I believe there's some difference because in my first attempts it was failing due to high packet loss/intermittent connection, but in my manual tests I was disabling WiFi.
  2. I have also noticed that corrupting the file using something like echo ha > packed.tgz did not produce the same effect (I assume pnpm correctly recognized corruption and redownloaded??). Something about file headers?
  3. There seem to be cases in which there is no integrity.json file (actually the case for my tests above!) and I'm not sure how that plays into the issue

@mnzaki
Copy link
Contributor
mnzaki commented Jan 20, 2018

Quick Fix

Changing

    if (err.code !== 'ENOENT') throw err

to

   if (err.code !== 'ENOENT' && err.code !== 'Z_BUF_ERROR') throw err

"solves" the issue (it will just redownload the file). Though I suspect it goes deeper than that: why is t even at this point of execution if packed.tgz is corrupt??

Also I would highly recommend a higher level exception handler (perhaps in packageRequester) that spits out the package name along with the exception, to mitigate these situations in the future.

@zkochan
Copy link
Member
zkochan commented Jan 20, 2018

This sounds good. I would additionally log a warning if the error is not ENOENT.

Does this error only happen with warm cache? Because the usecase you describe uses a tarball from cache

@mnzaki
Copy link
Contributor
mnzaki commented Jan 20, 2018

Well yes, a warm cache, with corrupted files.

@zkochan
Copy link
Member
zkochan commented Jan 20, 2018

Would you like to contribute this fix? Otherwise, I can probably fix it today or tomorrow

mnzaki added a commit to mnzaki/tarball-fetcher that referenced this issue Jan 20, 2018
@mnzaki
fix: don't die if cached tarball is corrupted
8cba1e5 
related to pnpm/pnpm#600
mnzaki added a commit to mnzaki/package-requester that referenced this issue Jan 20, 2018
@mnzaki
fix: report package name if fetching fails
2ac1451 
related to pnpm/pnpm#600
This was referenced Jan 20, 2018
Merged
Merged
zkochan pushed a commit to pnpm/package-requester that referenced this issue Jan 20, 2018
@mnzaki @zkochan
fix: report package name if fetching fails
102c47f 
related to pnpm/pnpm#600
mnzaki added a commit to mnzaki/tarball-fetcher that referenced this issue Jan 20, 2018
@mnzaki
fix: don't die if cached tarball is corrupted
b64feff 
related to pnpm/pnpm#600
zkochan pushed a commit to pnpm/tarball-fetcher that referenced this issue Jan 20, 2018
@mnzaki @zkochan
fix: don't die if cached tarball is corrupted (#4)
7cc49b0 
* add @pnpm/logger dependency

* test: redownload incomplete cached tarballs

* fix: don't die if cached tarball is corrupted

related to pnpm/pnpm#600
zkochan added a commit that referenced this issue Jan 20, 2018
@zkochan
fix: update dependencies
8ab0a83 
ref #989
ref #600
@zkochan
Copy link
Member
zkochan commented Jan 21, 2018

The fix was published with v1.30.1

@zkochan zkochan closed this as completed Jan 23, 2018
@arun290636
Copy link

@zkochan I am facing same problem with version 2.0.0.

Error:
{ Error: unexpected end of file at Gunzip.zlibOnError (zlib.js:152:15) errno: -5, code: 'Z_BUF_ERROR' } Error: unexpected end of file at Gunzip.zlibOnError (zlib.js:152:15)

@prakhar241
Copy link

This is true -

5520 silly fetchPackageMetaData error for material-design-icons@^3.0.1 unexpected end of file
5521 verbose stack Error: unexpected end of file
5521 verbose stack at Gunzip.zlibOnError (zlib.js:152:15)

5523 verbose Darwin 16.7.0
5524 verbose argv "/.nvm/versions/node/v8.4.0/bin/node" "/.nvm/versions/node/v8.4.0/bin/npm" "install"
5525 verbose node v8.4.0
5526 verbose npm v5.3.0
5527 error code Z_BUF_ERROR
5528 error errno -5
5529 error unexpected end of file
5530 verbose exit [ -5, true ]

I'm getting this again and again while npm install on home network.

@zkochan
Copy link
Member
zkochan commented Dec 11, 2018 •
edited
Loading

@prakhar241

I'm getting this again and again while npm install on home network.

npm? This pnpm's repo. If you have issues with npm, look here: https://npm.community/

@MuhammadBilalYar
Copy link

still facing this issue

@zkochan
Copy link
Member
zkochan commented Apr 22, 2019

Please create a new issue with steps to reproduce

@RobertLowe
Copy link

Still happening

@RobertLowe
Copy link

Screen Shot 2020-02-14 at 3 48 52 PM

Almost a consistent on/off pattern

@zkochan
Copy link
Member
zkochan commented Feb 15, 2020 via email

@dev-kvdabs
Copy link

Fixed with "npm cache clean --force'

@pnpm pnpm locked as resolved and limited conversation to collaborators Aug 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@zkochan zkochan

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@vjpr @RobertLowe @mnzaki @arun290636 @zkochan @prakhar241 @MuhammadBilalYar @dev-kvdabs
0