Maximum call stack size exceeded #16
Comments
|
I'm also getting a similar (or the same) error: My zip files are about 5Mb, most work fine (and some 300Mb haven't had any issues), but some don't. I might not be able to link to a failing zip file though as it's contains sensitive information :-( I did an npm update before posting here so should be on the latest version. |
|
Yeah, I saw your issue. It was closed and a patch issued, but I have cloned the latest code and still no luck. Not quite sure why it chokes, and it seems to be platform specific issue. On Heroku (less resources) it fails. On my local Mac, it works fine for the big files. |
|
I think I know the other issue your talking about, although it's not mine. I too cloned didn't have any joy. |
|
I'm also experiencing this issue sporadically :/ |
|
I've had a chance to look into this a little closer and have submitted a pull request (that's opened issue #17). Feel free give it a test. |
|
So far it's working on the use cases it was failing on for me. I will get back if I see anything different. Thank you! |
|
@timsweb @ralphholzmann @brianhiss Thanks for your help troubleshooting this issue. I wanted to get the fix in #17 up on NPM as soon as possible, so I published v0.1.5. That said, there's a lot of logic not really about parsing zips in parse.js / untilstream.js that would be more reliable as a module based on the Node 0.10 stream.Transform with its own tests. I'll leave this issue open until the logic's impending move barring problems with the match-stream module. Expect an update to this issue soon. I know some zips that have failed to extract in the past contain sensitive information and would appreciate your help again to test. |
|
@EvanOxfeld An user complained about this very same issue here: bower/bower#312 |
|
Really appreciate the test case, @satazor. I'll get it integrated into the |
|
I'm not sure if this is a useful clue or not, but for the same file I can repeatably cause #16 to break or not break by...wait for it...changing from 1 CPU to 2 CPUs! Configuration
1 CPU: Breaks every time
2 CPUs: Works every time
|
|
@EvanOxfeld Some more details on node 0.10.3bootstrap.zipvar unzip = require('unzip');
var fs = require('fs');
fs.createReadStream('bootstrap.zip')
.pipe(unzip.Extract({ path: 'test' }))
.on('error', function (err) { console.log('error', err); })
.on('close', function () { console.log('closed'); });Works! jquery-ui-1.10.0.custom.zipvar unzip = require('unzip');
var fs = require('fs');
fs.createReadStream('jquery-ui-1.10.0.custom.zip')
.pipe(unzip.Extract({ path: 'test' }))
.on('error', function (err) { console.log('error', err); })
.on('close', function () { console.log('closed'); });Fails.. it previously worked. Here's the stack trace: node 0.8.22bootstrap.zipIt just hangs while extracting, high CPU usage jquery-ui-1.10.0.custom.zipFails with the same error as the |
|
Thanks for the info @satazor - I'm close to a fix, at least for node 0.10.3. |
Recursively calling Parse._flush caused recursive process.nextTick calls. Fixes #16.
|
@EvanOxfeld after upgrading to 0.1.7, all issues present in my previous comment still exist. |
|
Is there any updates on this? It's currently a pressing issue for Bower. |
|
I have the same problem Node: 0.10.12 |
|
Just another sample: With the following modules: |
When I try to unzip a file on Heroku, I am getting a Maximum call stack size exceeded if the zip file contains a file of over ~110kb. If all files are less than that, it doesn't seem to matter how big the zip file itself is. Just seems to choke on files inside the zip if larger than ~110kb.
I am using pipe:
fs.createReadStream('test.zip').pipe(unzip.Extract({ path: 'test/' }))
Here is the Heroku crash log:
domain_thrown: true,
POST /config { [RangeError: Maximum call stack size exceeded]
domain:
{ domain: null,
_events: { error: [Function] },
_maxListeners: 10,
members: [ [Object], [Object] ] } }
The text was updated successfully, but these errors were encountered: