One of my customers says my app is crashing every time when he opens his MBP after many hours of inactivity. I have a hunch it has something to do with Appnap.

I use the below code in the App open event to disable Appnap.

dim SleepDisableHandle as NSProcessInfoActivityMBS
SleepDisableHandle = NSProcessInfoMBS.processInfo.beginActivity(NSProcessInfoMBS.NSActivityBackground, "Sync running")

Maybe an app that has Appnap disabled, triggers the App.open event after the system gets back from inactivity? Is this possible?

Also, is there a way to force the system to enter Appnap?

Crash log?

Here is a crash report:
Seems there are too many wake ups ?

Date/Time: 2018-07-02 16:19:18.344060 +1000
OS Version: Mac OS X 10.13.5 (Build 17F77)
Architecture: x86_64
Report Version: 19

Command: XDevices
Path: /Applications/01Apps/XDevices.app/Contents/MacOS/XDevices
Version: 1.1.1 (1.1.1)
Parent: launchd [1]
PID: 42602

Event: wakeups
Action taken: none
Wakeups: 45001 wakeups over the last 211 seconds (213 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds
Wakeups limit: 45000
Limit duration: 300s
Wakeups caused: 45001
Duration: 210.80s
Steps: 23

Hardware model: iMac15,1
Active cpus: 8

Fan speed: 1196 rpm

Powerstats for: ff·Works [42602]
UUID: A5F92A22-D802-3796-83E2-F467693DBC79
Start time: 2018-07-02 16:19:19 +1000
End time: 2018-07-02 16:22:48 +1000
Parent: launchd
Microstackshots: 23 samples (100%)
Primary state: 11 samples Frontmost App, User mode, Effective Thread QoS User Interactive, Requested Thread QoS User Interactive, Override Thread QoS Unspecified
User Activity: 0 samples Idle, 23 samples Active
Power Source: 0 samples on Battery, 23 samples on AC
20 start + 1 (libdyld.dylib) [0x7fff6aac7015]
20 main + 19 (ff·Works) [0x1044db7f3]
20 _Main + 478 (ff·Works) [0x1044dd90e]
20 REALbasic._RuntimeRun + 19 (ff·Works) [0x102b45b23]
20 RuntimeRun + 40 (XojoFramework) [0x104fbf17f]
20 -[NSApplication run] + 764 (AppKit) [0x7fff40246885]
20 ??? (XojoFramework + 865878) [0x104e40656]
20 CallFunctionWithExceptionHandling(void (*)()) + 262 (XojoFramework) [0x104fc0e53]
20 Application._CallFunctionWithExceptionHandling%%o<Application>p + 181 (ff·Works) [0x102a96045]
20 ??? (XojoFramework + 866029) [0x104e406ed]
20 ??? (XojoFramework + 865961) [0x104e406a9]
20 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 (AppKit) [0x7fff409e7e34]
19 _DPSNextEvent + 2085 (AppKit) [0x7fff40251a73]
19 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (HIToolbox) [0x7fff41f9f884]
18 ReceiveNextEventCommon + 613 (HIToolbox) [0x7fff41f9fb06]
18 RunCurrentEventLoopInMode + 286 (HIToolbox) [0x7fff41f9fd96]
18 CFRunLoopRunSpecific + 483 (CoreFoundation) [0x7fff42cb91a3]
13 __CFRunLoopRun + 2427 (CoreFoundation) [0x7fff42cb9dab]
11 __CFRunLoopDoTimers + 346 (CoreFoundation) [0x7fff42cc27da]
7 __CFRunLoopDoTimer + 1095 (CoreFoundation) [0x7fff42cc2cd7]
7 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 (CoreFoundation) [0x7fff42cc3064]
4 ??? (XojoFramework + 2474041) [0x104fc9039]
2 MainWindow.MainWindow.E7_Action%%o<MainWindow.MainWindow>o<Timer> + 506 (ff·Works) [0x103063f9a]
2 SecStaticCodeCheckValidityWithErrors + 163 (Security) [0x7fff4ebc5b42]
2 Security::CodeSigning::SecStaticCode::staticValidate(unsigned int, Security::CodeSigning::SecRequirement const*) + 71 (Security) [0x7fff4ebcd33d]
2 Security::CodeSigning::SecStaticCode::staticValidateCore(unsigned int, Security::CodeSigning::SecRequirement const*) + 47 (Security) [0x7fff4ebcf4a1]
2 Security::CodeSigning::SecStaticCode::validateExecutable() + 584 (Security) [0x7fff4ebc9e9c]
2 Security::CodeSigning::CodeDirectory::multipleHashFileData(Security::UnixPlusPlus::FileDesc, unsigned long, std::__1::set<unsigned int, std::__1::less<unsigned int>, std::__1::allocator<unsigned int> >, void (unsigned int, Security::DynamicHash*) block_pointer) + 416 (Security) [0x7fff4ebd7cec]
2 Security::makeCFMutableDictionary() + 27 (Security) [0x7fff4ece0c2c]
2 CFDictionaryCreateMutable + 207 (CoreFoundation) [0x7fff42c3ea3f]
2 CFBasicHashCreate + 827 (CoreFoundation) [0x7fff42c3711b]
2 CFBasicHashGetPtrIndex + 77 (CoreFoundation) [0x7fff42c375bd]
1 MainWindow.MainWindow.E9_Action%%o<MainWindow.MainWindow>o<Timer> + 791 (ff·Works) [0x103069d67]
1 SecStaticCodeCheckValidityWithErrors + 163 (Security) [0x7fff4ebc5b42]
1 Security::CodeSigning::SecStaticCode::staticValidate(unsigned int, Security::CodeSigning::SecRequirement const*) + 71 (Security) [0x7fff4ebcd33d]
1 Security::CodeSigning::SecStaticCode::staticValidateCore(unsigned int, Security::CodeSigning::SecRequirement const*) + 47 (Security) [0x7fff4ebcf4a1]
1 Security::CodeSigning::SecStaticCode::validateExecutable() + 584 (Security) [0x7fff4ebc9e9c]
1 Security::CodeSigning::CodeDirectory::multipleHashFileData(Security::UnixPlusPlus::FileDesc, unsigned long, std::__1::set<unsigned int, std::__1::less<unsigned int>, std::__1::allocator<unsigned int> >, void (unsigned int, Security::DynamicHash*) block_pointer) + 411 (Security) [0x7fff4ebd7ce7]
1 Security::CodeSigning::scanFileData(Security::UnixPlusPlus::FileDesc, unsigned long, void (void const*, unsigned long) block_pointer) + 145 (Security) [0x7fff4ebf3cb1]
1 invocation function for block in Security::CodeSigning::CodeDirectory::multipleHashFileData(Security::UnixPlusPlus::FileDesc, unsigned long, std::__1::set<unsigned int, std::__1::less<unsigned int>, std::__1::allocator<unsigned int> >, void (unsigned int, Security::DynamicHash*) block_pointer) + 50 (Security) [0x7fff4ebd7deb]

That's not a crashlog. Whatever is happing here is to do with your code signing and what you do to check the code signing.

Not sure what you mean. I just use Appwrapper with no specific options enabled.

Normally crash logs look like this:

Time Awake Since Boot: 1000000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff93b25f06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff853a34ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff8ee066df abort + 129
3 org.python.python 0x0000000105c39f71 Py_FatalError + 65
4 org.python.python 0x0000000105c3bd23 _Py_InitializeEx_Private + 1379
5 com.mothsoftware.fix_encoding 0x0000000100002a1f 0x100000000 + 10783
6 com.mothsoftware.fix_encoding 0x0000000100000f7d main + 333
7 com.mothsoftware.fix_encoding 0x0000000100000e04 start + 52

But perhaps the different format comes from the cause of the crash.

The report is full with stuff from code signing:

1 invocation function for block in Security::CodeSigning::CodeDirectory::multipleHashFileData(Security::UnixPlusPlus::FileDesc, unsigned long, std::__1::set<unsigned int, std::__1::less<unsigned int>, std::__1::allocator<unsigned int> >, void (unsigned int, Security::DynamicHash*) block_pointer) + 50 (Security) [0x7fff4ebd7deb]

@Beatrix W Normally crash logs look like this:

But perhaps the different format comes from the cause of the crash.

The report is full with stuff from code signing:

It is code signed though. Maybe Sam can put some light on this?

MainWindow.MainWindow.E7_Action%%o<MainWindow.MainWindow>o<Timer> + 506 (ff·Works) [0x103063f9a]

This is the last line of the report before it did a code sign check and deep within Apple's code sign checking system it failed (out of our hands). The most common problem is a failure for it to communicate with Apple's web servers.

I've seen similar issues where the code sign tools can crash if they can't reach Apple's code sign servers!

This is intentional. Xojo now uses higher Mac SDK version, so Apple expects that you as developer know about it.

e.g. use NSProcessInfoMBS class

@ChristianSchmitz This is intentional. Xojo now uses higher Mac SDK version, so Apple expects that you as developer know about it.

e.g. use NSProcessInfoMBS class

Now that you bring that up - is there a way to prevent it for launched processes as well? I'm still running into situations where my helpers are being "de-prioritized" all the way to Zombie state after 10s of hours of running.

Are these helper apps console or GUI apps? I think (thought?) that console apps were immune from app nap. Are you seeing console apps get "de-prioritized" too? I don't see a priority column option under Activity Monitor > View > Columns so what are you using to verify the de-prioritized state?

They are C/C++ console apps. Yes - I've actually watched my task drop in priority and finally end up Zombied and disconnected from the UI even though the Shell is still running after a period of days. This can happen when a user starts a long process that may prompt for use input, but they are out for the weekend and don't see the prompt until Monday.

Also, you won't see these processes in Activity Monitor - you will need to use "ps" or "top".

@Douglas H Are these helper apps console or GUI apps? I think (thought?) that console apps were immune from app nap.

By default they were; but there's no guarantee that's valid now.

In my own application which uses the code documented by Apple, so that it can perform a long task (like 40+ minutes), failed to prevent the machine from going to sleep after 5 minutes. When I returned, I expected it to be completed. I haven't investigated it further after confirming that I'm using the right code.

There is just so much that's broke nowadays, it's really sad.

@Sam R There is just so much that's broke nowadays, it's really sad.

Not only sad but scary. I have helper apps which run on a headless mac mini. The GUI portion (accessed remotely) uses the app nap disable stuff but the console apps I have always treated as app nap proof. This makes me worried about ever upgrading the OS on them. I can't let those processes be Zombied because they are not monitored frequently.

Do we know when this broke?

@Douglas H Not only sad but scary. I have helper apps which run on a headless mac mini. The GUI portion (accessed remotely) uses the app nap disable stuff but the console apps I have always treated as app nap proof. This makes me worried about ever upgrading the OS on them. I can't let those processes be Zombied because they are not monitored frequently.

My advice would be to a) don't upgrade this machine and b) look into alternative (and less costly solutions) in the future. Remember Xojo can target Windows, Linux and PI, none of which (AFAIK) do these "energy saving" measures. Which to be honest, I am happy Apple implemented that, but sad, they they're just left broken.

@Douglas Handy Do we know when this broke?

I don't to be honest. I only recently created a project that does LONG tasks, so I can't say I ever actually the option that's meant to stop the machine from going to sleep until this year.

@ChristianSchmitz If app nap is disabled this way, will that also prevent the OSX screensaver from cutting in while the app is running in the foreground (doing some sort of activity) without the user interacting with either mouse or keyboard? If not, is there another way that I can prevent the screensaver from coming on?