FOOM (fatal out of memory error) not being recorded?

[fosterbrereton]

I am trying to solidify the crash reporting story of my iOS app. On a 12.9" iPad Pro the following code causes the application to terminate due to an out of memory error. Upon relaunch the HockeyApp SDK does not appear to record a crash:

+(void) fatalMemoryAllocation {
    constexpr auto size_k{1024UL * 1024 * 1024}; // 1GiB
    while (true) {
        volatile auto foo = new char[size_k];
        std::fill(foo, foo + size_k, 42);
        NSLog(@"Allocated %ld bytes", size_k);
    }
}

Are FOOMs not recorded/logged like traditional crash reports are? What am I missing?

[Jamminroot]

Hey, @fosterbrereton, thanks for getting in touch! We've checked this problem (with provided code in specific) on a few machines, and could not reproduce the issue. Can the problem be in the debugger being attached? Also, can you provide verbose logs to help us locate the origin of issue? Thanks.

[fosterbrereton]

When attached to the Xcode debugger, I see something like the following:

2019-06-24 16:49:38.828157-0700 MyApp[28852:792758] Allocated 1073741824 bytes
Message from debugger: Terminated due to memory issue

When I am not attached to the debugger, there is no output anywhere except for the console of the device:

default 20:59:13.099559 -0700   MyApp Allocated 1073741824 bytes
default 20:59:13.552536 -0700   kernel  EXC_RESOURCE -> MyApp[29847] exceeded mem limit: ActiveHard 3072 MB (fatal)
default 20:59:13.552690 -0700   kernel  464154.287 memorystatus: killing_specific_process pid 29847 [MyApp] (per-process-limit 10) - memorystatus_available_pages: 50959

HockeyApp produces no crash reports for this kind of crash, so unfortunately that's all the logging information I have.

Both of the above were generated with a 12.9" iPad Pro.

[Jamminroot]

I mean you can call the crash without debugger attached, then launch app with debugger attached to be able to get logs on what has happened. I will re-check that meanwhile.

[Jamminroot]

After a more thourough investigation, we were able to reproduce the issue. It appears that trying to allocate 1gb per iteration might disallow to reproduce the issue. Changing this amount helped us out. Memory allocation error can lead to 2 different ways of app being terminated: throwing C++ std::bad_alloc exception and process termination by OS. Since we are using in-process crash detection, first one can be detected, while the latter one can not - it isn't mapped to signals interceptable by in-process crash detection. In your example, the SDK is not able to catch a crash since the application is killed by OS.

[fosterbrereton]

Thanks for the information. The crash I’m interested in is the process termination- we are handling exceptions just fine in our app.

I noticed in the log an EXC_RESOURCE mach exception was being sent to the application prior to the crash. What kind of mach exception support exists in HockeyApp? Could it be modified to accommodate include support for this kind of exception?

[elamalani]

@fosterbrereton This is a new feature request in HockeySDK. Please note that we are not adding new features in HockeyApp which will sunset on November 16, 2019. App Center is the next generation solution for HockeyApp and I'd recommend you to move your apps to App Center in the coming weeks. We can track it as a new feature request in App Center.

[fosterbrereton]

@elamalani Thanks. We're in the process of migrating to App Center. I posted a similar issue there but it was closed as a duplicate of this issue. Should I reopen?

[elamalani]

@fosterbrereton Yea, it would be great if you could reopen the ticket on App Center repo and let's close this one.

[fosterbrereton]

Filed, thanks.

[lumaxis]

@fosterbrereton While I think the App Center SDK does not yet have this feature, you could try using https://www.hockeyapp.net/help/sdk/ios/5.1.4/Classes/BITCrashManager.html#/c:objc(cs)BITCrashManager(py)enableAppNotTerminatingCleanlyDetection now that you are still using the HockeySDK. It's not 100% accurate and can include reports from other reasons but it should theoretically provide you with info about how often your app gets killed for using too much memory.