How to determine the cause of an out of memory crash

I cannot post ips crashes reports file due to the "sensitive language" restriction when posting the message, any ideas on what kind of information the Apple bot can consider sensitive ?

Here is the crash reports :

1. Crash report file at format IPS

You posted your crash report in a way that makes it hard to access. Can you try again, this time without the leading “1.”? I believe that’s confusing the DevForums platform )-:

ps I have general advice on how to post crash reports in… you guess it!… Posting a Crash Report.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello,

Thanks for your reply. Ok, I send it again.

Thanks

Thanks for the latest crash reports. It turns out that they were still rendering incorrectly. I tracked that down to a bug in the DevForums platform (r. 132309185). I’ve did some minor edits on your post to work around that bug.

And so, back to your crash reports, which I’ll look at in groups.

In the first crash report I see this:

Last Exception Backtrace:
0   CoreFoundation    … __exceptionPreprocess + 160
1   libobjc.A.dylib   … objc_exception_throw + 56
2   borne             … 0x104800000 + 1919724
3   borne             … 0x104800000 + 1919792
4   CoreFoundation    … __NSDICTIONARY_IS_CALLING_OUT_TO_A_BLOCK__ + 16
5   CoreFoundation    … __NSDictionaryEnumerate + 628
6   borne             … 0x104800000 + 1919292
7   borne             … 0x104800000 + 1911312
8   borne             … 0x104800000 + 1910916
9   borne             … 0x104800000 + 1915068
10  libdispatch.dylib … _dispatch_call_block_and_release + 24

This indicates that your ap crashed due to an unhandled language exception. That exception was throw directly by your app, in frame 2, so I’ve no insight into what caused it. You need to symbolicate your crash report to identify the code in frame 2. For advice on how to do that, see Adding identifiable symbol names to a crash report.

Your second and third crash reports are virtually identical, so I’m going to focus on the second.

The immediate cause of the crash is this:

Exception Type:  EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000

This shows that your app crashed because it dereferenced a NULL pointer. Normally the next step is to look at the backtrace of the crashing thread:

Thread 1 name:  JavaScriptCore bmalloc scavenger
Thread 1 Crashed:
0 libsystem_kernel.dylib  … __psynch_cvwait + 8
1 libsystem_pthread.dylib … _pthread_cond_wait$VARIANT$mp + 1232
2 libc++.1.dylib          … std::__1::condition_variable::wait(std::__1::unique_lock&) + 24
3 NativeScript            … void std::__1::condition_variable_any::wait>(std::__1::unique_lock&) + 108
4 NativeScript            … bmalloc::Scavenger::threadRunLoop() + 160
5 NativeScript            … bmalloc::Scavenger::threadEntryPoint(bmalloc::Scavenger*) + 12
6 NativeScript            … void* std::__1::__thread_proxy>, void (*)(bmalloc::Scavenger*), bmalloc::Scavenger*…
7 libsystem_pthread.dylib … _pthread_start + 104
8 libsystem_pthread.dylib … thread_start + 8

This is problematic because that thread is parked in the __psynch_cvwait system call. It’s very hard for a parked thread to crash in this way.

Looking through all your other threads, they seem to be similarly parked. The exception is thread 0, the main thread, which has a long and complex backtrace:

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0:
0  ???          … ???
1  CoreImage    … CI::GLContext::GLContext(CI::GLContext::ShareContextInfo, CGColorSpace*, CGColorSpace*, CI::P…
2  CoreImage    … +[CIContext(Internal) internalContextWithEAGLContext:options:] + 664
3  CoreImage    … -[CIContext initWithOptions:] + 484
4  CoreImage    … +[CIContext contextWithOptions:] + 36
5  UIKitCore    … -[_UIImageCIImageRenderer _updateContextForHDRRendering:] + 224
6  UIKitCore    … -[_UIImageCIImageRenderer renderContent:usingHDR:withEffects:] + 196
7  UIKitCore    … -[UIImageView _setImageViewContentsForCIImageBackedImage:] + 344
8  UIKitCore    … -[UIImageView _setImageViewContents:] + 368
9  UIKitCore    … -[UIImageView _updateState] + 524
10 UIKitCore    … -[UIImageView _setViewGeometry:forMetric:] + 328
11 NativeScript … ffi_call_SYSV + 68
12 NativeScript … ffi_call_int + 1172
13 NativeScript … ffi_call + 56
14 NativeScript … NativeScript::FunctionWrapper::call(JSC::ExecState*) + 592
…

This is exactly the sort of backtrace I’d typically see for a SIGSEGV.

It’s seems very likely that something about your third-party runtime is disrupting the Apple crash report. I see this regularly in apps that use their own crash reporter. That’s something I specifically recommend against, as I explain in Implementing Your Own Crash Reporter.

Without a trustworthy crash report, it’ll be hard to make progress on this issue.

Oh, one last thing:

P.S : I formatted ips file in valid JSON format

Please don’t do that. The weird .ips format is what’s expected by our crash reporting tools. If you fix it, it confuses those tools )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello,

Thanks for your reply. Sorry about reformating ips file, didn't get that.

I'm about to post again ips without any modification, if it can help you.

if it can help you.

Thanks. But it doesn’t actually help in this case.

IMO your next step should be to look at your third-party runtime to see if there’s an obvious reason why it can cause the system to generate crash reports that doen’t make sense.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello,

I can find dSYM files from the framework but I unfortunately didn't succeed to symbolicate my crash report with that file, I can see yet which binary image cause the crash, and to be honest, I'm pretty confused by all this stuff because I'm not an usual Apple Developer. Usually we count on the framework abstraction and we develop our app like a web one.

Crash files that I could retrieve does not seem to have the same format as ones mentionned in the link you provided to me.

I have a bunch of dSYM files but I cannot determine which is the right file to analyze. And even if I find the symbol name of the function that cause this dereferencing, I'm not sure at all that I will be able to find a fix to remedy the bug. And the runtime of the framework is not maintained anymore for more than 2 years.

Crash files that I could retrieve does not seem to have the same format as ones mentionned in the link you provided to me.

I talk about the common Apple crash report formats in this post. If you have a crash report in some other format, that’s likely the result of a custom crash reporter.

I can see yet which binary image cause the crash

Going back to your second crash report, you can identify the binary image that caused the crash by correlating the image name with the Binary Images section. Consider:

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0:
0   ???                           	               0x0 ???
1   CoreImage                     	       0x1a6cd5dcc CI::GLContext::
        GLContext(CI::GLContext::ShareContextInfo, CGColorSpace*, 
        CGColorSpace*, CI::PixelFormat, bool, unsigned long, unsigned long, 
        bool, bool) + 504
…

Binary Images:
…
       0x1a6afb000 -        0x1a6e4efff CoreImage arm64  
            <106ce42b8d353591801eab399e643125> 
            /System/Library/Frameworks/CoreImage.framework/CoreImage
…

Note I’ve added line breaks to make things easier to read in the context of a forums post.

Thus, frame 1 is running code from CoreImage which has a UUID of 106ce42b8d353591801eab399e643125.

However, I don’t think that helps you much, because the vast majority of your frames are from your NativeScript runtime. That looks like a fork of JavaScriptCore. However, it’s not using the JavaScriptCore that’s built in to iOS, but instead has its own copy.

And the runtime of the framework is not maintained anymore for more than 2 years.

Are you talking about your internal framework? Or NativeScript? Because the latter seems to be a going concern.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"