jrr6 / caffeinator Goto Github PK

Issue

If Caffeinator is terminated using killall, Activity Monitor, or some other mechanism that is not the in-app menu item, the active caffeinate sub-process (if it exists) is not properly terminated and continues to run, even after the Caffeinator instance is terminated.

Steps to Reproduce

• Open Caffeinator
• Start a Caffeination
• Use Activity Monitor to quit Caffeinator, or execute killall Caffeinator in the Terminal
• Observe (using ps aux | grep caffeinate or Activity Monitor) that the caffeinate process is still active

Proposed Resolution

No specific means of resolution has been decided upon at this time.

Issue

If "Prompt Before Executing" is enabled and the user open the process-based Caffeination dialog, enters a PID, but then cancels the Caffeination on the pre-execution prompt, the text of the "Caffeinate a Process…" label will still change to "Caffeinating [App Name/PID]" in the Caffeinator menu. This is because the change to the text is occurring in processClicked, which is unaware of the possibility of cancelation in generateCaffeine.

Steps to Reproduce

• Enable "Prompt Before Executing" in the "Advanced" menu
• Select "Caffeinate a Process…" and enter a PID
• On the prompt that follows, select "Cancel"

Proposed Resolution

The process name lookup and label text changing should probably occur in generateCaffeine, after ensuring that the Caffeination has not been canceled in the pre-execution prompt.

Issue

If the Caffeinator menu is opened after the pre-execution prompt or an input dialog is opened, the app crashes as soon as the dialog is closed (this does not affect error dialogs or the Check for Update dialog). It has been confirmed that runModalInFront is always being called on the main thread.

Steps to Reproduce

• Start Caffeinator in timed mode/Caffeinate a Process/start Caffeinator with Prompt Before Executing enabled (generate one of the relevant pop-up dialogs)
• Re-open, then close, the Caffeinator menu while the dialog is open
• Close out of the dialog (Cancel/OK)
• App crashes

Issue

Using the Caffeinator suite in JXA causes a memory leak when accessing properties on the caffeination object (e.g., options, active).

Steps to Reproduce

The following script will cause about .3–.5 MB to be leaked (whereas the commented bottom-most line—using the Application suite—causes no leak):

for (i = 0; i < 2000; i++) {
    if (Application("Caffeinator").caffeination.active() == true) { "active" } else { "stopped" }
    // if (Application("Caffeinator").caffeination.options() == []) { "none" } else { "some" }
    // console.log(Application('Caffeinator').version())
}

The leak has no correspondence to the size of the data returned by Caffeinator (e.g., causing options to always return a 100-element array leaks no more memory than having options always be empty). Even after replacing ScriptingCaffeination with a dummy class that does no meaningful computation, the leak remains.

After 30 minutes of periodic AppleScript events (triggered by two-second polling by BetterTouchTool), leaked memory totaled approximately 2.4 MB. Over extended use, hundreds of megabytes have been observed to leak. Instruments does not seem to detect these cumulative leaks, but rather detects only a single, initial, 16-byte leak of category Security::CodeSigning::SecStaticCode::ValidationContext. Allocations seem to stem from AEProcessAppleEvent in the call tree.

Proposed Resolution

Continue investigating behavior and source of memory leak. This may have to do with the design of OSA and how scripting is implemented.