Beta 1.2.0 partially hanging on long compressions

[Darklocq]

Using the 1.2.0-dev beta that had the ACE stuff added in for testing. Seems to be 1.2.0-dev (3701), more specifically. I mostly use Keka as just a Dock drop target to do nothing but 7Z (max) compression. I'm finding that it seems to (partially) hang more than 50% of the time on any fairly large/long compressions, and is more apt to do so, it seems, when switching focus away from the app to do something else. The progress bar stops, you get a "beachball" cursor, and if you leave the app, nothing happens when you try to get back into it (by Dock icon click or by Cmd-Tab). It will often work right on a second or later attempt, but not always. In reality, the app is actually still working in the background, as can be confirmed by keeping an eye on the file size of the archive being written out. However, after it is done, it does not play its sound, and the app remains unresponsive.

For example, I kept getting a "beachball" in the app when compressing a 1.3 GB Native Instruments Maschine library (one big file) I don't need any time soon. It guestimates 6 minutes (at my performance settings), and becomes unresponsive after about 1 (but actually got the job done in 10–15). The non-beta version has no trouble with the file, and gets the job done in about 1.5 minutes (though hogging CPU and RAM), plays its completion sound, and is working properly afterward (in my case it quits unless I have it open doing something else, as intended). The beta version just sits there, stuck. The archive it created while semi-hung tests out as valid (in The Archive Browser).

I'm doubting this has to do with the ACE addition, since extracting ACEs and compressing 7Zs wouldn't seem to related to each other. But who knows.

I am testing some of the new Performance settings:

• Max. sim. ops.: 2
• Max. sim. comp.: 1
• Max. sim. extr.: 2
• Max. thread/op.: 2

(Aside: I can confirm that this stuff works to stop the app from using up all available RAM and CPU, at the cost of speed, as expected.)

File access is volume-wide on every volume. Inherit quarantine is off. Default action: always compress. Compression: 7z, slowest/most. Save: next to original, same base name. Exclude res. forks. Play sound when done. Ask before quit, enable Notification Ctr., use unified toolbar, close app when no windows open, auto-updates off. Keka not set as default app for anything.

Oh, and as I noted elsewhere, it crashed to desktop one time, after running the beta for the first time and opening preferences and picking some panes to look at.

System: macOS 10.13.6, mid-2010 Mac Pro, 40 GB RAM, loads of disk/SSD space.

[Darklocq]

In other thread about the ACE 2.x beta, I uploaded crash/hang logs. Also, I don't think this really has anything to do with length of the compression operation, but mostly with the app losing user "focus", though I also got it to crash another way (trying to write to directory without proper permissions), as reported at the other ticket. This ticket is probably a duplicate. Mostly, if you switch away from the app it just hangs, though as noted above sometimes part of it is still running and will eventually get the compression job done, though it will not tell you that it is done. On average, it just seems to hang completely. Meanwhile, if you leave it as the frontmost app, it will generally work normally.

[Darklocq]

That archive file of crash logs is toward the (current) end of #402.

[aonez]

This reminds me to #119. I'll double check that Keka is informing the activity to the OS in the latest beta.

[aonez]

I can't reproduce this one, on 10.13 or 10.14.

[Darklocq]

As I noted elsewhere, the dev version you pointed me to a couple of weeks ago was still hanging whenever I would switch out of the application (e.g. to finder). I found that it would complete the compression job if it was a short one (like a minute or less), but would die completely after a while on a long job. It would still complete the job without any kind of hanging as long as the app retained OS focus the entire time. That's under macOS 10.13.6. Is there another dev version to try?

[aonez]

The latest one is https://github.com/aonez/Keka/releases/tag/v1.2.0-dev.3742, but I think you've already tried it. I was unable to reproduce the issue involving the focus...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Darklocq]

Any ideas? It's weird that you cannot reproduce it in macOS 10.13, but for me in 10.13 it is 100% reproducible.

[Darklocq]

PS: #402 is where I last uploaded relevant logs/dumps.

[aonez]

Any ideas? It's weird that you cannot reproduce it in macOS 10.13, but for me in 10.13 it is 100% reproducible.

Can you reproduce it in another machine (not the Mac Pro 2010) with 10.13?

[Darklocq]

I don't have another machine on which to run 10.13, nor any machine on which to run 10.14+ (my Mac will not do 10.14 without a hardware upgrade).

[Darklocq]

Dev version 1013 of Keka [it says Version 1.2.0-dev (3748) in its Get Info window] has resolved this.

Thank you!