"Prevent App Nap" check box not available for Cocoa builds

  1. ‹ Older
  2. 11 months ago

    Christoph D

    12 Jul 2018 Pre-Release Testers, Xojo Pro
    Edited 11 months ago

    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?

  3. Christian S

    13 Jul 2018 Pre-Release Testers, Xojo Pro, XDC Speakers Germany

    Crash log?

  4. Christoph D

    14 Jul 2018 Pre-Release Testers, Xojo Pro

    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]

  5. Beatrix W

    14 Jul 2018 Pre-Release Testers Europe (Germany)

    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.

  6. Christoph D

    14 Jul 2018 Pre-Release Testers, Xojo Pro

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

  7. Beatrix W

    14 Jul 2018 Pre-Release Testers Europe (Germany)

    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]

  8. Christoph D

    14 Jul 2018 Pre-Release Testers, Xojo Pro

    @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?

  9. Sam R

    14 Jul 2018 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan
    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!

  10. 7 months ago

    I'm running Sierra, and I just noticed that I cannot anymore prevent/allow app nap. But I'm sure it worked before installing Sierra.
    My tests done with (1) Sam's RedBull and (2) using Thomas T's Preferences (cfr. macoslib).

    What I see is that Activity Monitor shows Yes/No only for the Finder and Safari. All other apps are stuck at No.
    May be it is time, at least for me, to forget about using Prevent App Nap.

  11. Christian S

    26 Nov 2018 Pre-Release Testers, Xojo Pro, XDC Speakers Germany

    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

  12. Now I know. Thanks.

  13. Tim J

    27 Nov 2018 Pre-Release Testers, Xojo Pro Dehydrating in AZ

    @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.

  14. Douglas H

    27 Nov 2018 Pre-Release Testers, Xojo Pro

    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?

  15. Tim J

    27 Nov 2018 Pre-Release Testers, Xojo Pro Dehydrating in AZ

    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.

  16. Tim J

    27 Nov 2018 Pre-Release Testers, Xojo Pro Dehydrating in AZ

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

  17. Sam R

    27 Nov 2018 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @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.

  18. Douglas H

    27 Nov 2018 Pre-Release Testers, Xojo Pro

    @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?

  19. Sam R

    28 Nov 2018 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @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.

  20. David M

    28 Nov 2018 Pre-Release Testers, Xojo Pro

    @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?

  21. If I recall right, one way to prevent screensaver from coming on, is to use a timer set to something like 30000:

    Declare sub UpdateSystemActivity lib "CoreServices" (val as integer)
    UpdateSystemActivity(1)

  22. Newer ›

or Sign Up to reply!