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

  1. ‹ Older
  2. last year

    Christoph D

    14 Jul 2018 Pre-Release Testers, Xojo Pro

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

  3. 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]

  4. 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?

  5. 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!

  6. 8 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.

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

  8. Now I know. Thanks.

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

  10. 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?

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

  12. 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".

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

  14. 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?

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

  16. 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?

  17. 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)

  18. Newer ›

or Sign Up to reply!