App Crash in UnzipKit

[iblacksun]

My app using UnzipKit 1.4.x, I did get some crash log showing it crashed in UnzipKit,but it happens randomly and rarely.
I thinks here is a similar issue http://stackoverflow.com/questions/18511762/nscalendar-datefromcomponents-crashes-with-sigabrt

[abbeycode]

Interesting. It definitely looks like it could be a concurrency problem (based on the Stack Overflow link). Are you calling UnzipKit from multiple threads? If possible, could you give some of your calling code?

[iblacksun]

Yes, in a GCD queue.

let saveFileQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)
......
dispatch_async(saveFileQueue){
    ......
    let zipArchive = try UZKArchive(path: zipFilePath, password: "xxxx")
    ....
    try zipArchive.writeData(data, filePath: filename)
}

[iblacksun]

@abbeycode More information, my dummy code:

let zipArchive = try UZKArchive(path: zipFilePath, password: "xxxx")
for ... {
    try zipArchive.writeData(data, filePath: filename)
}

[abbeycode]

I've been trying to reproduce this in a test case, and have been unsuccessful (not even once), which will make it difficult to verify any fix. Are you writing the the same zipFilePath from multiple queued operations? That would definitely cause problems, so I haven't tried that in my test cases. This is what my most recent one looks like:

func test_Issue23() {
    let saveFileQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)

    let fileCount = 50
    let archiveCount = 1_000
    let password = "password"

    var expectations = [XCTestExpectation]()

    for i in 1...archiveCount {
        let expectation = self.expectationWithDescription("create archive #\(i)")
        expectations.append(expectation)

        dispatch_async(saveFileQueue) {
            let archivePath = self.tempDirectory.URLByAppendingPathComponent("archive \(i).zip")
            let archive = try! UZKArchive(path: archivePath.path!, password: password)

            for x in 1...fileCount {
                let data = "file \(x)".dataUsingEncoding(NSUTF8StringEncoding)
                let path = "\(x)/file \(x).txt"
                try! archive.writeData(data!, filePath: path)
            }

            expectation.fulfill()
        }
    }

    self.waitForExpectationsWithTimeout(30) {error in
        if let error = error {
            NSLog("Error while waiting for expectations: \(error)")
        }
    }
}

I don't know if there's any more I can do try to reproduce it. Do you have any ideas?

I've got an idea for a possible fix, but am hesitant to release it without verification in a test. Are you currently using Carthage or CocoaPods? If you're using Carthage, I can try the fix in a branch, which you can point your Cartfile to, and see if your crashes go away. About how often were you getting them, anyway?

[iblacksun]

I have update my code, add a synchronize when calling archive.writeData.
I am watching crashes and if this update is ok, i will tell you, otherwise require your Carthage branch.
Thank you very much.

[abbeycode]

How are you synchronizing? If it's a global sync on archive.writeData, that's a workaround (rather than a solution) and I'd still like to fix it in the library. If you're synchronizing on each file, so that multiple writes to a particular file get serialized, that would be a proper client-side fix.

[iblacksun]

I'm using client-side fix.

@synchronizing(self){
   archive.writeData
}

But now i don't have enough crashes to check if this workaround is OK.

[abbeycode]

But won't that slow your code down? If you only write one file at a time, then what's the point of performing those operations asynchronously at all?

I still plan to try putting my fix in a branch soon for you to try it out. This feels like it should be fixed on my end, rather than in each client.

[iblacksun]

Yes, it will slow my code.
You can fix this in a branch, but my next version will one month later. During this month, i will interaction your branch in my developing app.

[iblacksun]

@abbeycode And, please add bundle id for iOS target.

[abbeycode]

When I look at the UnzipKit.framework produced by Carthage, I see com.abbey-code.UnzipKit as the CFBundleIdenfitier. What are you seeing?

[abbeycode]

You can try out the issue23 branch, which should hopefully solve the concurrency issue. As mentioned, I couldn't reproduce the issue in a test case, so I can't verify.