search

twolfson / grunt-zip

Zip and unzip files via a grunt plugin
MIT License
87 stars 19 forks source link

Unzipping does nothing with long syntax #30

Closed fefrei closed 10 years ago

fefrei commented 10 years ago

With node.js v0.10.31 and grunt-cli v0.1.13, grunt v0.4.4, an unzip task doesn't seem to do anything if in long syntax: It complains if the source is missing, but outputs nothing (and returns unusually fast) if it exists. Using the short syntax works (but, of course, doesn't let you specify options).

The relevant fragment of my configuration is:

grunt.initConfig({
    unzip: {
        ace: {
            src: 'managed_components/ace/ace-' + aceVersion + '.zip',
            dest: 'managed_components/ace/build/'
        }
    }
}

The full configuration is here: https://secure.fefrei.de/redmine/projects/concurrent-programming-web/repository/revisions/88ede4a566ed92971aaada2e93b977ad0868b3ef/entry/Gruntfile.js

The full output of grunt unzip:ace is:

Running "unzip:ace" (unzip) task
fefrei commented 10 years ago

It also does not just not work: It also cancels execution of further tasks, without causing any errors. Running "unzip:ace" (unzip) task is the last thing that will appear in the console output.

twolfson commented 10 years ago

Could you elaborate on not working? Is that with the long/short syntax? What do you mean cancels execution of further tasks?

twolfson commented 10 years ago

The test suite runs with the long syntax and has no issues:

https://github.com/twolfson/grunt-zip/blob/0.16.0/test/grunt.js#L62-L65

Can you provide a copy of the zip file for closer inspection?

fefrei commented 10 years ago

If I use the short syntax for unzip in my Gruntfile.js (as in your example: gallery: 'photos.zip'), everything works as expected (but I can't control the output path).

Using the long syntax (as with the unzip:ace task shown above), grunt just stops without any further output - so not just the unzip-task stops, but the whole run of grunt.

I don't think the actual ZIP file is the culprit (since it depends in the syntax in the config file), but you can grab it here: https://github.com/ajaxorg/ace-builds/archive/v1.1.6.zip

I'm running Windows 8.1 64-bit.

twolfson commented 10 years ago

Awesome, thanks for providing the info. I am busy at the moment but will take a look by the end of Sunday.

fefrei commented 10 years ago

I experimented a bit. Interestingly, the ZIP-file plays an important role.

I can reproduce the issue on my system using a minimal working example I made available here: http://extern.fefrei.de/20140829/grunt-zip-mwe.zip Unzip these files to a new directory, and npm install it. Running grunt demonstrates the erratic behavior. If you replace file2.zip with another ZIP file - e.g. a copy of file1.zip - there are no issues at all.

For reference, here is a shell session demonstrating the issue, and displaying version information: https://secure.fefrei.de/paste/?b6b2f1cc9d32818e#BV2Xan2m7E17j/It3hjn90zxbIqwUDabvvAE4TF7WMw=

Thank you very much for looking into this.

twolfson commented 10 years ago

Taking a look now. For reference, gists (gist.github.com) are the preferred way to share proof of concepts for issues. I took the file and pushed it here:

https://gist.github.com/twolfson/380352db4ff0ae3b7c94

twolfson commented 10 years ago

Alright, it seems to work on Linux Mint 14. I am guessing this is a Windows issue. Looking into that.

twolfson commented 10 years ago

Windows 7 seems to look fine against node@0.10.26, grunt-cli@0.1.11, and grunt@0.4.5. I am going to match up versions to see if that makes it reproducable.

twolfson commented 10 years ago

Woot, issue has been reproduced against node@0.10.31, grunt-cli@0.1.13, and grunt@0.4.4. Looking into the culprit now.

twolfson commented 10 years ago

It looks like node@0.10.31 is the culprit. After bringing it back to Linux, I am seeing a segfault error:

$ grunt
Running "unzip:one" (unzip) task
Created "one" directory

Running "unzip:two" (unzip) task
Segmentation fault (core dumped)
twolfson commented 10 years ago

Moving to node@0.10.30 seems to resolve the issue. Looking into a more accurate issue to file against joyent/node or point us to.

twolfson commented 10 years ago

After following the instructions from a relevant issue, it looks like we are in the same boat as:

https://github.com/joyent/node/issues/8208

Here is my segfault-handler log for future reference:

PID 4948 received SIGSEGV for address: 0x8
/home/todd/github/gist-grunt-zip-30/node_modules/segfault-handler/build/Release/segfault-handler-native.node(+0x101d)[0x7fe65927a01d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fe65984bcb0]
node(_ZN2v88internal12HInstruction11InsertAfterEPS1_+0x58)[0x7759d8]
node(_ZN2v88internal17BoundsCheckBbData10CoverCheckEPNS0_12HBoundsCheckEi+0xa0)[0x7a6580]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x2f9)[0x78d049]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEPNS0_11HBasicBlockEPNS0_16BoundsCheckTableE+0x18b)[0x78cedb]
node(_ZN2v88internal6HGraph30EliminateRedundantBoundsChecksEv+0x4f)[0x79f97f]
node(_ZN2v88internal6HGraph8OptimizeEPNS0_17SmartArrayPointerIcEE+0x12f)[0x7a1f7f]
node(_ZN2v88internal18OptimizingCompiler13OptimizeGraphEv+0x34)[0x6ffea4]
node[0x701067]
node(_ZN2v88internal8Compiler11CompileLazyEPNS0_15CompilationInfoE+0x1e4)[0x701774]
node[0x7f87db]
node(_ZN2v88internal10JSFunction16CompileOptimizedENS0_6HandleIS1_EENS0_9BailoutIdENS0_18ClearExceptionFlagE+0xa0)[0x8218e0]

https://github.com/ddopson/node-segfault-handler

fefrei commented 10 years ago

Great. Thank you for your awesome work!