This repository has been archived by the owner on Aug 11, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 43
Maximum call stack size exceeded #1
Comments
I think this is a result of the graceful-fs library wrapping fs more than once. |
isaacs
added a commit
to isaacs/node-graceful-fs
that referenced
this issue
Dec 3, 2011
Should be fixed on the latest release. Let me know if it's still a problem after updating tar and fstream. (Incidentally, if you isntall graceful-fs in the top-level root, it would "work by accident", since they'd share the dep.) |
Yep, all fixed now - thanks heaps for the speedy fix. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
OK - this is a strange one, but with some effort I've been able to replicate it. It looks like when two packages both have a dependency on fstream and those two packages are then included in a project, you end up with call stack exceeded errors.
I found this when building http:https://github.com/steelmesh/attachmate which has been made to work with the fstream module, and I think it works pretty well.
Unfortunately when I got to using both attachmate and tar in a project, I started seeing call stack errors :(
I've created a test project @ https://github.com/DamonOehlman/fstream-callstack-test which replicates the issue, and to be honest I'm not sure if this is an fstream issue or a node issue... sorry. I've generated a module debug log at https://github.com/DamonOehlman/fstream-callstack-test/blob/master/module-debug.log which might shed some light on things too.
Anything else I can do, then please let me know. Dead keen to make use of fstream for other things :)
Cheers,
Damon.
The text was updated successfully, but these errors were encountered: