I'm trying to profile a Xamarin.Mac app with the mono profiler, but I encounter errors. The app is built locally for debugging with Visual Studio for Mac and built for the App Store using the MSBuild CLI.
I tried this:
Build the app through Visual Studio for Mac, with Full debug information
mono --profile=log "MyApp.app/Contents/MonoBundle/MyApp.exe"
which failed with
stdout:
aot-runtime.c:2441: Image out of date assembly:/Users/chase/MyApp/MyAppWeb/projects/MyApp.Mac/bin/Debug/MyApp (Dev).app/Contents/MonoBundle/MyApp (Dev).exe.dylib type:<unknown type> member:(null) signature:<none>
stderr:
Stacktrace:
Native stacktrace:
0 mono 0x000000010578ebf8 mono_handle_native_crash + 264
1 libsystem_platform.dylib 0x00007fff5fa03f5a _sigtramp + 26
2 mono 0x0000000105abb148 pvars + 328
3 libsystem_c.dylib 0x00007fff5f7a11ae abort + 127
4 mono 0x000000010599cb0f mono_log_write_logfile + 351
5 mono 0x00000001059b551e monoeg_g_log + 206
6 mono 0x00000001059a2cc6 mono_error_assert_ok_pos + 54
7 mono 0x000000010577512f decode_cached_class_info + 447
8 mono 0x0000000105775530 mono_aot_get_cached_class_info + 432
9 mono 0x0000000105856d5c mono_class_init + 364
10 mono 0x0000000105700f38 mono_method_to_ir + 86040
11 mono 0x00000001056d8807 mini_method_compile + 3287
12 mono 0x00000001056dbf16 mono_jit_compile_method_inner + 790
13 mono 0x00000001056df4d2 mono_jit_compile_method_with_opt + 1442
14 mono 0x00000001056e2f25 mono_jit_runtime_invoke + 501
15 mono 0x00000001058dbab4 do_runtime_invoke + 84
16 mono 0x00000001058df079 do_exec_main_checked + 137
17 mono 0x0000000105750b0f mono_jit_exec + 287
18 mono 0x0000000105753a8d mono_main + 11069
19 mono 0x00000001056d2c4d main + 253
20 mono 0x00000001056d2b44 start + 52
Debug info from gdb:
(lldb) command source -s 0 '/tmp/mono-gdb-commands.MwIxeR'
Executing commands in '/tmp/mono-gdb-commands.MwIxeR'.
(lldb) process attach --pid 3702
warning: (x86_64) /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/4.5/mscorlib.dll.dylib empty dSYM file detected, dSYM was created with an executable with no debug info.
Process 3702 stopped
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x00007fff5f846232 libsystem_kernel.dylib`__wait4 + 10
libsystem_kernel.dylib`__wait4:
-> 0x7fff5f846232 <+10>: jae 0x7fff5f84623c ; <+20>
0x7fff5f846234 <+12>: movq %rax, %rdi
0x7fff5f846237 <+15>: jmp 0x7fff5f83cb25 ; cerror
0x7fff5f84623c <+20>: retq
Target 0: (mono) stopped.
Executable module set to "/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono".
Architecture set to: x86_64h-apple-macosx.
(lldb) thread list
Process 3702 stopped
* thread #1: tid = 0x1e6e4, 0x00007fff5f846232 libsystem_kernel.dylib`__wait4 + 10, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
thread #2: tid = 0x1e6e7, 0x00007fff5f845a1e libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
thread #3: tid = 0x1e6e8, 0x00007fff5f83c246 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
thread #4: tid = 0x1e6e9, 0x00007fff5f83c246 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Profiler sampler'
thread #5: tid = 0x1e6ea, 0x00007fff5f845cfa libsystem_kernel.dylib`__select + 10, name = 'Profiler helper'
thread #6: tid = 0x1e6eb, 0x00007fff5f83c246 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Profiler writer'
thread #7: tid = 0x1e6ec, 0x00007fff5f83c25e libsystem_kernel.dylib`semaphore_timedwait_trap + 10, name = 'Profiler dumper'
(lldb) thread backtrace all
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x00007fff5f846232 libsystem_kernel.dylib`__wait4 + 10
frame #1: 0x000000010578ec9f mono`mono_handle_native_crash(signal=<unavailable>, ctx=<unavailable>, info=<unavailable>) at mini-exceptions.c:2830 [opt]
frame #2: 0x00007fff5fa03f5a libsystem_platform.dylib`_sigtramp + 26
frame #3: 0x00007fff5f845b6f libsystem_kernel.dylib`__pthread_kill + 11
frame #4: 0x00007fff5fa10080 libsystem_pthread.dylib`pthread_kill + 333
frame #5: 0x00007fff5f7a11ae libsystem_c.dylib`abort + 127
frame #6: 0x000000010599cb0f mono`mono_log_write_logfile(log_domain=<unavailable>, level=<unavailable>, hdr=<unavailable>, message="aot-runtime.c:2441: Image out of date assembly:/Users/chase/MyApp/MyAppWeb/projects/MyApp.Mac/bin/Debug/MyApp (Dev).app/Contents/MonoBundle/MyApp (Dev).exe.dylib type:<unknown type> member:(null) signature:<none>\n") at mono-log-common.c:135 [opt]
frame #7: 0x00000001059b551e mono`monoeg_g_log [inlined] monoeg_g_logv at goutput.c:115 [opt]
frame #8: 0x00000001059b54d8 mono`monoeg_g_log(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>) at goutput.c:125 [opt]
frame #9: 0x00000001059a2cc6 mono`mono_error_assert_ok_pos(error=<unavailable>, filename="aot-runtime.c", lineno=2441) at mono-error.c:171 [opt]
frame #10: 0x000000010577512f mono`decode_cached_class_info(module=<unavailable>, info=<unavailable>, buf=" \x10À(\x12", endbuf=0x00007ffeea52ed68) at aot-runtime.c:2441 [opt]
frame #11: 0x0000000105775530 mono`mono_aot_get_cached_class_info(klass=<unavailable>, res=<unavailable>) at aot-runtime.c:2515 [opt]
frame #12: 0x0000000105856d5c mono`mono_class_init [inlined] mono_class_get_cached_class_info(klass=0x00007fba84e0c1c8, res=<unavailable>) at class.c:8958 [opt]
frame #13: 0x0000000105856d44 mono`mono_class_init(klass=0x00007fba84e0c1c8) at class.c:4975 [opt]
frame #14: 0x0000000105700f38 mono`mono_method_to_ir(cfg=<unavailable>, method=<unavailable>, start_bblock=0x00007fba8681f430, end_bblock=0x00007fba8681f580, return_var=0x0000000000000000, inline_args=0x00007fba8681fe28, inline_offset=<unavailable>, is_virtual_call=<unavailable>) at method-to-ir.c:8404 [opt]
frame #15: 0x00000001056d8807 mono`mini_method_compile(method=<unavailable>, opts=370239999, domain=0x00007fba84c0a040, flags=JIT_FLAG_RUN_CCTORS, parts=0, aot_method_index=-1) at mini.c:3440 [opt]
frame #16: 0x00000001056dbf16 mono`mono_jit_compile_method_inner(method=0x00007fba84c0b928, target_domain=0x00007fba84c0a040, opt=370239999, error=0x00007ffeea52f688) at mini.c:4181 [opt]
frame #17: 0x00000001056df4d2 mono`mono_jit_compile_method_with_opt(method=0x00007fba84c0b928, opt=<unavailable>, jit_only=<unavailable>, error=0x00007ffeea52f688) at mini-runtime.c:2129 [opt]
frame #18: 0x00000001056e2f25 mono`mono_jit_runtime_invoke [inlined] mono_jit_compile_method(method=<unavailable>, error=0x00007ffeea52f688) at mini-runtime.c:2175 [opt]
frame #19: 0x00000001056e2f01 mono`mono_jit_runtime_invoke(method=0x00007fba84c0b928, obj=<unavailable>, params=0x00007ffeea52f648, exc=0x0000000000000000, error=<unavailable>) at mini-runtime.c:2687 [opt]
frame #20: 0x00000001058dbab4 mono`do_runtime_invoke(method=0x00007fba84c0b928, obj=0x0000000000000000, params=0x00007ffeea52f648, exc=0x0000000000000000, error=0x00007ffeea52f688) at object.c:2887 [opt]
frame #21: 0x00000001058df079 mono`do_exec_main_checked [inlined] mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, error=<unavailable>) at object.c:3040 [opt]
frame #22: 0x00000001058df038 mono`do_exec_main_checked(method=0x00007fba84c0b928, args=<unavailable>, error=0x00007ffeea52f688) at object.c:4784 [opt]
frame #23: 0x0000000105750b0f mono`mono_jit_exec(domain=<unavailable>, assembly=<unavailable>, argc=1, argv=0x00007ffeea52fa18) at driver.g.c:1210 [opt]
frame #24: 0x0000000105753a8d mono`mono_main [inlined] main_thread_handler at driver.g.c:1287 [opt]
frame #25: 0x0000000105753a59 mono`mono_main(argc=<unavailable>, argv=<unavailable>) at driver.g.c:2417 [opt]
frame #26: 0x00000001056d2c4d mono`main [inlined] mono_main_with_options(argc=<unavailable>, argv=<unavailable>) at main.c:47 [opt]
frame #27: 0x00000001056d2c39 mono`main(argc=3, argv=<unavailable>) at main.c:340 [opt]
frame #28: 0x00000001056d2b44 mono`start + 52
thread #2, name = 'SGen worker'
frame #0: 0x00007fff5f845a1e libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff5fa0e589 libsystem_pthread.dylib`_pthread_cond_wait + 732
frame #2: 0x0000000105993ffe mono`thread_func [inlined] mono_os_cond_wait(mutex=<unavailable>) at mono-os-mutex.h:173 [opt]
frame #3: 0x0000000105993feb mono`thread_func at sgen-thread-pool.c:165 [opt]
frame #4: 0x0000000105993fdd mono`thread_func(data=0x0000000000000000) at sgen-thread-pool.c:196 [opt]
frame #5: 0x00007fff5fa0d661 libsystem_pthread.dylib`_pthread_body + 340
frame #6: 0x00007fff5fa0d50d libsystem_pthread.dylib`_pthread_start + 377
frame #7: 0x00007fff5fa0cbf9 libsystem_pthread.dylib`thread_start + 13
thread #3, name = 'Finalizer'
frame #0: 0x00007fff5f83c246 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x0000000105941a9c mono`finalizer_thread [inlined] mono_os_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:90 [opt]
frame #2: 0x0000000105941a91 mono`finalizer_thread at mono-coop-semaphore.h:43 [opt]
frame #3: 0x0000000105941a85 mono`finalizer_thread(unused=<unavailable>) at gc.c:852 [opt]
frame #4: 0x00000001058fd960 mono`start_wrapper [inlined] start_wrapper_internal at threads.c:1004 [opt]
frame #5: 0x00000001058fd8c3 mono`start_wrapper(data=<unavailable>) at threads.c:1064 [opt]
frame #6: 0x00007fff5fa0d661 libsystem_pthread.dylib`_pthread_body + 340
frame #7: 0x00007fff5fa0d50d libsystem_pthread.dylib`_pthread_start + 377
frame #8: 0x00007fff5fa0cbf9 libsystem_pthread.dylib`thread_start + 13
thread #4, name = 'Profiler sampler'
frame #0: 0x00007fff5f83c246 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x00000001058eaf3b mono`mono_profiler_sampling_thread_wait [inlined] mono_os_sem_wait(flags=MONO_SEM_FLAGS_NONE) at mono-os-semaphore.h:90 [opt]
frame #2: 0x00000001058eaf24 mono`mono_profiler_sampling_thread_wait at profiler.c:536 [opt]
frame #3: 0x00000001058308c7 mono`sampling_thread_func(data=<unavailable>) at mini-posix.c:643 [opt]
frame #4: 0x00007fff5fa0d661 libsystem_pthread.dylib`_pthread_body + 340
frame #5: 0x00007fff5fa0d50d libsystem_pthread.dylib`_pthread_start + 377
frame #6: 0x00007fff5fa0cbf9 libsystem_pthread.dylib`thread_start + 13
thread #5, name = 'Profiler helper'
frame #0: 0x00007fff5f845cfa libsystem_kernel.dylib`__select + 10
frame #1: 0x0000000105c08bde libmono-profiler-log.0.dylib`helper_thread(arg=<unavailable>) at log.c:3773 [opt]
frame #2: 0x00007fff5fa0d661 libsystem_pthread.dylib`_pthread_body + 340
frame #3: 0x00007fff5fa0d50d libsystem_pthread.dylib`_pthread_start + 377
frame #4: 0x00007fff5fa0cbf9 libsystem_pthread.dylib`thread_start + 13
thread #6, name = 'Profiler writer'
frame #0: 0x00007fff5f83c246 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x0000000105c0987b libmono-profiler-log.0.dylib`writer_thread [inlined] mono_os_sem_wait at mono-os-semaphore.h:90 [opt]
frame #2: 0x0000000105c09862 libmono-profiler-log.0.dylib`writer_thread(arg=<unavailable>) at log.c:4009 [opt]
frame #3: 0x00007fff5fa0d661 libsystem_pthread.dylib`_pthread_body + 340
frame #4: 0x00007fff5fa0d50d libsystem_pthread.dylib`_pthread_start + 377
frame #5: 0x00007fff5fa0cbf9 libsystem_pthread.dylib`thread_start + 13
thread #7, name = 'Profiler dumper'
frame #0: 0x00007fff5f83c25e libsystem_kernel.dylib`semaphore_timedwait_trap + 10
frame #1: 0x0000000105c0a3d2 libmono-profiler-log.0.dylib`dumper_thread [inlined] mono_os_sem_timedwait(timeout_ms=1000, flags=MONO_SEM_FLAGS_NONE) at mono-os-semaphore.h:124 [opt]
frame #2: 0x0000000105c0a3be libmono-profiler-log.0.dylib`dumper_thread(arg=<unavailable>) at log.c:4118 [opt]
frame #3: 0x00007fff5fa0d661 libsystem_pthread.dylib`_pthread_body + 340
frame #4: 0x00007fff5fa0d50d libsystem_pthread.dylib`_pthread_start + 377
frame #5: 0x00007fff5fa0cbf9 libsystem_pthread.dylib`thread_start + 13
(lldb) detach
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Process 3702 detached
(lldb) quit
My mono version is
Mono JIT compiler version 5.10.1.57 (2017-12/ea8a24b1bbf Tue Apr 24 14:53:01 EDT 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: normal
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(3.6.0svn-mono-master/8b1520c8aae)
GC: sgen (concurrent by default)
How can I fix this issue? More generally, how can I profile a Xamarin.Mac app bundle with the mono profiler?
Related question: Running Instruments on a Xamarin.Mac application bundle, which asks about profiling with Instruments for Mac instead of with the mono profiler.
EDIT
MONO_ENV_OPTIONS
I tried Filip Navara's answer
Xamarin.Mac has a particular startup sequence and embeds a particular version of the Mono runtime with it. By running "mono" directly you bypass the startup sequence and it can cause problems. The proper way is to use the MONO_ENV_OPTIONS environment variable to pass the options: MONO_ENV_OPTIONS=--profile=log MyApp.app/Contents/MacOS/MyApp.
but I get an error:
echo $MONO_ENV_OPTIONS
MONO_ENV_OPTIONS=--profile=log /Users/chase/MyApp/MyAppWeb/projects/MyApp.Mac/bin/Debug/MyApp.app/Contents/MacOS/MyApp
cd /Users/chase/MyApp/MyAppWeb/projects/MyApp.Mac/bin/Debug/MyApp.app/Contents/MacOS/
./MyApp
Cannot open assembly '/Users/chase/MyApp/MyAppWeb/projects/MyApp.Mac/bin/Debug/MyApp.app/Contents/MacOS/MyApp': File does not contain a valid CIL image.
If I clear MONO_ENV_OPTIONS, then I do not get the error, and the application runs correctly (but, of course, the profiler does not run).
I am not sure if it will help with your particular error, but here's couple of hints.
Xamarin.Mac has a particular startup sequence and embeds a particular version of the Mono runtime with it. By running "mono" directly you bypass the startup sequence and it can cause problems. The proper way is to use the MONO_ENV_OPTIONS environment variable to pass the options: MONO_ENV_OPTIONS=--profile=log MyApp.app/Contents/MacOS/MyApp.
Alternative way to profile the application is to adapt the MonoDevelop code. It uses the system sample tool and then post-processes the output to translate opaque function offsets into .NET method names.
Related
This is very annoying, every time I'm trying to debug on the simulator with "all exception break point", app stops for no reason on this line:
return UIApplicationMain(argc, argv, nil, NSStringFromClass([STAppDelegate class]));
Did any one else found him self struggling with this issue?
Thanks!
EDIT
Back trace on first throw:
thread #1: tid = 0x1d96b, 0x36fbf540 libc++abi.dylib`__cxa_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 3.2
frame #0: 0x36fbf540 libc++abi.dylib`__cxa_throw
frame #1: 0x306975cc libFontParser.dylib`TFileDescriptorContext::TFileDescriptorContext(char const*) + 112
frame #2: 0x306973d8 libFontParser.dylib`TFileDataReference::TFileDataReference(char const*) + 164
frame #3: 0x306971fc libFontParser.dylib`TFileDataSurrogate::TFileDataSurrogate(char const*, bool) + 188
frame #4: 0x3069555a libFontParser.dylib`TFont::CreateFontEntitiesForFile(char const*, bool, TSimpleArray<TFont*>&, bool, short, char const*) + 1402
frame #5: 0x30694a80 libFontParser.dylib`FPFontCreateFontsWithPath + 224
frame #6: 0x2a5032bc libCGXType.A.dylib`create_private_data_with_path + 12
frame #7: 0x2a3ca3c4 CoreGraphics`CGFontCreateFontsWithPath + 24
frame #8: 0x2a4855d6 CoreGraphics`CGFontCreateFontsWithURL + 310
frame #9: 0x313dfee4 GraphicsServices`AddFontsFromURLOrPath + 68
frame #10: 0x313e39de GraphicsServices`__Initialize_block_invoke + 934
frame #11: 0x0121fabe libdispatch.dylib`_dispatch_client_callout + 22
frame #12: 0x01220750 libdispatch.dylib`dispatch_once_f + 100
frame #13: 0x313df72c GraphicsServices`Initialize + 196
frame #14: 0x377944c4 libobjc.A.dylib`_class_initialize + 536
frame #15: 0x3779a046 libobjc.A.dylib`lookUpImpOrForward + 254
frame #16: 0x37799f3e libobjc.A.dylib`_class_lookupMethodAndLoadCache3 + 34
frame #17: 0x377a01f8 libobjc.A.dylib`_objc_msgSend_uncached + 24
frame #18: 0x2d673b6e UIKit`-[UIStatusBarNewUIForegroundStyleAttributes makeTextFontForStyle:] + 78
frame #19: 0x2d634d94 UIKit`-[UIStatusBarForegroundStyleAttributes textFontForStyle:] + 104
frame #20: 0x2d5e767e UIKit`-[UIStatusBarServiceItemView updateForContentType:serviceString:serviceCrossfadeString:maxWidth:actions:] + 390
frame #21: 0x2d5e74ee UIKit`-[UIStatusBarServiceItemView updateForNewData:actions:] + 186
frame #22: 0x2d6428d0 UIKit`-[UIStatusBarItemView initWithItem:data:actions:style:] + 324
frame #23: 0x2d642568 UIKit`-[UIStatusBarLayoutManager _createViewForItem:withData:actions:] + 108
frame #24: 0x2d5e6f74 UIKit`-[UIStatusBarLayoutManager _prepareEnabledItemType:withEnabledItems:withData:actions:itemAppearing:itemDisappearing:] + 264
frame #25: 0x2d5e6e22 UIKit`-[UIStatusBarLayoutManager prepareEnabledItems:withData:actions:] + 74
frame #26: 0x2d5e6c72 UIKit`-[UIStatusBarForegroundView _setStatusBarData:actions:animated:] + 162
frame #27: 0x2d5e6b96 UIKit`-[UIStatusBarForegroundView setStatusBarData:actions:animated:] + 710
frame #28: 0x2d671ebe UIKit`__44-[UIStatusBar _prepareToSetStyle:animation:]_block_invoke + 358
frame #29: 0x2d5fc230 UIKit`+[UIView(Animation) performWithoutAnimation:] + 72
frame #30: 0x2d66fcf4 UIKit`-[UIStatusBar _prepareToSetStyle:animation:] + 688
frame #31: 0x2d6579ca UIKit`-[UIStatusBar _requestStyleAttributes:animationParameters:] + 290
frame #32: 0x2d65696e UIKit`-[UIStatusBar requestStyle:animated:] + 86
frame #33: 0x2d65559a UIKit`-[UIApplication _createStatusBarWithRequestedStyle:orientation:hidden:] + 406
frame #34: 0x2d85122a UIKit`-[UIApplication _runWithMainScene:transitionContext:completion:] + 970
frame #35: 0x2d85bc68 UIKit`__84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke + 36
frame #36: 0x2d84fc5a UIKit`-[UIApplication workspaceDidEndTransaction:] + 130
frame #37: 0x3086c0e0 FrontBoardServices`__31-[FBSSerialQueue performAsync:]_block_invoke + 12
frame #38: 0x2a13782c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
frame #39: 0x2a136af0 CoreFoundation`__CFRunLoopDoBlocks + 216
frame #40: 0x2a13564a CoreFoundation`__CFRunLoopRun + 1714
frame #41: 0x2a082db0 CoreFoundation`CFRunLoopRunSpecific + 476
frame #42: 0x2a082bc2 CoreFoundation`CFRunLoopRunInMode + 106
frame #43: 0x2d653c36 UIKit`-[UIApplication _run] + 558
frame #44: 0x2d64ea30 UIKit`UIApplicationMain + 1440
* frame #45: 0x003b4ec2 Stox`main(argc=1, argv=0x01200b08) + 178 at main.m:17
Third:
thread #1: tid = 0x1d96b, 0x36fbf540 libc++abi.dylib`__cxa_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 3.2
frame #0: 0x36fbf540 libc++abi.dylib`__cxa_throw
frame #1: 0x30798c22 libTrueTypeScaler.dylib`ScalerNewBlock(memoryContext*, long, long, void*, unsigned char, unsigned char) + 430
frame #2: 0x3077e172 libTrueTypeScaler.dylib`OutlineToPath(memoryContext*, fnt_ElementType const*) + 178
frame #3: 0x3079502a libTrueTypeScaler.dylib`ObtainDesiredOutline(memoryContext*, fnt_ElementType const*, unsigned long, void**) + 10
frame #4: 0x3077e07c libTrueTypeScaler.dylib`RenderPath(fsg_SplineKey*, memoryContext*, scalerGlyph const*) + 36
frame #5: 0x3077c980 libTrueTypeScaler.dylib`TTRenderGlyphs + 436
frame #6: 0x306c5722 libFontParser.dylib`TConcreteFontScaler::CopyGlyphPath(unsigned short, CGAffineTransform const*) const + 378
frame #7: 0x306a0ce6 libFontParser.dylib`FPFontCopyGlyphPath + 494
frame #8: 0x2a3abb4a CoreGraphics`CGFontCreateGlyphPath + 30
frame #9: 0x2a3aba56 CoreGraphics`CGFontCreateGlyphBitmap + 266
frame #10: 0x2a3b3c1a CoreGraphics`CGGlyphBuilder::create_missing_bitmaps(CGGlyphIdentifier const*, unsigned long, CGGlyphBitmap const**) + 82
frame #11: 0x2a6fd4dc libRIP.A.dylib`render_glyphs + 172
frame #12: 0x2a6fcaca libRIP.A.dylib`draw_glyph_bitmaps + 906
frame #13: 0x2a6fc430 libRIP.A.dylib`ripc_DrawGlyphs + 1108
frame #14: 0x2a3a1002 CoreGraphics`draw_glyphs + 274
frame #15: 0x2aaae268 CoreText`DrawSbixGlyphsAtPositions(TFont const*, CGFont*, TCFRef<__CFData const*> const&, unsigned short const*, CGPoint const*, unsigned long, CGContext*, CGAffineTransform, CGAffineTransform) + 1880
frame #16: 0x2aa6bcce CoreText`CTFontDrawGlyphsWithAdvances + 470
frame #17: 0x349eba1a UIFoundation`__NSStringDrawingEngine + 6710
frame #18: 0x349efa64 UIFoundation`-[NSAttributedString(NSExtendedStringDrawing) drawWithRect:options:context:] + 532
frame #19: 0x2d603370 UIKit`-[UILabel _drawTextInRect:baselineCalculationOnly:] + 4440
frame #20: 0x2d668ed4 UIKit`-[UILabel drawTextInRect:] + 488
frame #21: 0x2d668ce8 UIKit`-[UILabel drawRect:] + 84
frame #22: 0x2d668c70 UIKit`-[UIView(CALayerDelegate) drawLayer:inContext:] + 400
frame #23: 0x2d045910 QuartzCore`-[CALayer drawInContext:] + 228
frame #24: 0x2d02f350 QuartzCore`CABackingStoreUpdate_ + 2068
frame #25: 0x2d110b6c QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 52
frame #26: 0x2d02eb34 QuartzCore`x_blame_allocations + 88
frame #27: 0x2d02e7e4 QuartzCore`CA::Layer::display_() + 1156
frame #28: 0x2d012d9c QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 200
frame #29: 0x2d012a60 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 24
frame #30: 0x2d012446 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 222
frame #31: 0x2d012250 QuartzCore`CA::Transaction::commit() + 324
frame #32: 0x2d5e51c8 UIKit`_afterCACommitHandler + 132
frame #33: 0x2a137844 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
frame #34: 0x2a134f28 CoreFoundation`__CFRunLoopDoObservers + 276
frame #35: 0x2a13532a CoreFoundation`__CFRunLoopRun + 914
frame #36: 0x2a082db0 CoreFoundation`CFRunLoopRunSpecific + 476
frame #37: 0x2a082bc2 CoreFoundation`CFRunLoopRunInMode + 106
frame #38: 0x313e7050 GraphicsServices`GSEventRunModal + 136
frame #39: 0x2d64ea30 UIKit`UIApplicationMain + 1440
* frame #40: 0x003b4ec2 Stox`main(argc=1, argv=0x01200b08) + 178 at main.m:17
I was just experiencing the same exact problem and tracked down the issue.
Make sure that all fonts that you specify in your Info.plist under Fonts provided by this application are actually in your application bundle.
There's a more accurate way of tracking down the suspect font in your app using the debugger and the fact that it's conveniently stopped at the call.
Step 1: Reproduce the __cxa_throw breakpoint
Usually this happens when instantiating one of (or possibly the first) UIView object in your app. You'll see your debugger has broken and you'll have a stack such as this:
Step 2: Select the entry in the stack trace with the symbol FPFontCreateFontsWithPath
In my case, this entry was line 7 in the stack.
If you take a look at the disassembly, you'll notice the function signature of this entry:
Ah, cool! Looks like it takes some C strings. I betcha one of those is a filepath too!
Step 3: Locate that string in the app memory
I'm running this in a (x86_64) simulator, which on my computer stores the function arguments in some of the registers beginning with r. More details on registers here.
Either press Shift+Command+M or select the "Debug > Debug Workflow > View Memory" option from the menu.
At the bottom of this view, go through the registers one by one and enter the addresses. In my case, r14 contained the path of the file.
Alright, so now I know the font that's messed up. It's looking for HelveticaNeue.ttc. Let's find the reference to that in the project.
Open a terminal, navigate to your project and run:
$ ~/W/X/project> grep -R "HelveticaNeue" ./
.//MyProject/Main.Storyboard: <array key="HelveticaNeue.ttc">
.//MyProject/Main.Storyboard: <string>HelveticaNeue</string>
.//MyProject/Main.Storyboard: <fontDescription key="fontDescription" name="HelveticaNeue" family="Helvetica Neue" pointSize="18"/>
Awesome, now either switch those to system by replacing name="HelveticaNeue" family="Helvetica Neue" with type="system", open the storyboard and manually edit them or add a reference to the missing font to your app (info.plist and target).
Step 4: Celebrate 🎉 🎊 🍾 🍻
As the backtrace shows, the app didn't stop for no reason. It stopped because an exception was thrown, and it looks like a C++ exception.
Unlike Objective-C, where exceptions should only be thrown as the result of programming errors and therefore are very rare, there is a lot of C++ code around that throws and catches lots of exceptions. In that situation, probably best to only set a breakpoint on Objective-C exceptions, not all exceptions.
If you didn't find a problem in .plist file maybe the problem is in your .storyboard file..
Open it as source code from Xcode or in textView from Finder -
search for <customFonts key="customFonts">
I had there some old irrelevant array/font inside...:) just deleted it and it stopped
In my case the reference was inside xcuserdata :
user$ grep -R "HelveticaNeue" ./
Binary file .//MyProject.xcworkspace/xcuserdata/user.xcuserdatad/UserInterfaceState.xcuserstate matches
An exception is being thrown, but the caller (e.g. in libFontParser and libTrueTypeScaler) is handling it and it is not reaching your program.
Unless you see other evidence of a problem (such as a log message) or the exception reaches your program, assume that the implementation is handling it. You can continue past these instances in the debugger without worry.
I solved this issue by combining nmock's answer with DaNLtR's answer.
So at first i looked for <customFonts key="customFonts"> and there was Montserrat-Light present in it.
But it wasn't neither present in info.plist nor was it added to the project.
The problem vanished once i bundled Montserrat-Light.ttf into the project and added an entry for this font under Fonts provided by this application in info.plist.
So following is the summary of above mentioned solution:
Look for your Storyboard or Xib files for any Custom Fonts.
You'll find them in <customFonts key="customFonts">
If there is Actually a Custom Font mentioned, then follow steps 3 and 4
Add the font to your Xcode Project.
Add an entry to info.plist under Fonts provided by this application.
This entry should be name of the font file followed by its extension.
In case if <customFonts key="customFonts"> doesn't contain any Custom Font (e.g: Helvetica-Neue etc), then try deleting the <customFonts key="customFonts"> entry in Stroyboard or Xib file as stated in DaNLtR's answer
I know its very late to answer but hope this helps someone.
I get the message, 'Thread 1: breakpoint 1.1' after I run my code in xcode, which I believe is referring to the exception breakpoint, 'All Exceptions' I've added. The 'Thread 1: breakpoint 1.1' shows up highlighting in green the thread in my main file
return UIApplicationMain(argc, argv, nil, NSStringFromClass([CardGameAppDelegate class]));
My debugger console only says, '(lldb)'. After running 'bt' (backtrace) in the console, this is what is returned:
* thread #1: tid = 0x1b2bb4, 0x015748b9 libobjc.A.dylib`objc_exception_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x015748b9 libobjc.A.dylib`objc_exception_throw
frame #1: 0x01884fe1 CoreFoundation`-[NSException raise] + 17
frame #2: 0x01234d9e Foundation`-[NSObject(NSKeyValueCoding) setValue:forUndefinedKey:] + 282
frame #3: 0x011a11d7 Foundation`_NSSetUsingKeyValueSetter + 88
frame #4: 0x011a0731 Foundation`-[NSObject(NSKeyValueCoding) setValue:forKey:] + 267
frame #5: 0x01202b0a Foundation`-[NSObject(NSKeyValueCoding) setValue:forKeyPath:] + 412
frame #6: 0x004eb1f4 UIKit`-[UIRuntimeOutletConnection connect] + 106
frame #7: 0x015867de libobjc.A.dylib`-[NSObject performSelector:] + 62
frame #8: 0x017f076a CoreFoundation`-[NSArray makeObjectsPerformSelector:] + 314
frame #9: 0x004e9d4d UIKit`-[UINib instantiateWithOwner:options:] + 1417
frame #10: 0x003526f5 UIKit`-[UIViewController _loadViewFromNibNamed:bundle:] + 280
frame #11: 0x00352e9d UIKit`-[UIViewController loadView] + 302
frame #12: 0x003530d3 UIKit`-[UIViewController loadViewIfRequired] + 78
frame #13: 0x003535d9 UIKit`-[UIViewController view] + 35
frame #14: 0x00273267 UIKit`-[UIWindow addRootViewControllerViewIfPossible] + 66
frame #15: 0x002735ef UIKit`-[UIWindow _setHidden:forced:] + 312
frame #16: 0x0027386b UIKit`-[UIWindow _orderFrontWithoutMakingKey] + 49
frame #17: 0x0027e3c8 UIKit`-[UIWindow makeKeyAndVisible] + 65
frame #18: 0x0022ebc0 UIKit`-[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 2097
frame #19: 0x00233667 UIKit`-[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 824
frame #20: 0x00247f92 UIKit`-[UIApplication handleEvent:withNewEvent:] + 3517
frame #21: 0x00248555 UIKit`-[UIApplication sendEvent:] + 85
frame #22: 0x00235250 UIKit`_UIApplicationHandleEvent + 683
frame #23: 0x037eaf02 GraphicsServices`_PurpleEventCallback + 776
frame #24: 0x037eaa0d GraphicsServices`PurpleEventCallback + 46
frame #25: 0x01770ca5 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
frame #26: 0x017709db CoreFoundation`__CFRunLoopDoSource1 + 523
frame #27: 0x0179b68c CoreFoundation`__CFRunLoopRun + 2156
frame #28: 0x0179a9d3 CoreFoundation`CFRunLoopRunSpecific + 467
frame #29: 0x0179a7eb CoreFoundation`CFRunLoopRunInMode + 123
frame #30: 0x00232d9c UIKit`-[UIApplication _run] + 840
frame #31: 0x00234f9b UIKit`UIApplicationMain + 1225
* frame #32: 0x0000509d Matchismo`main(argc=1, argv=0xbfffedd8) + 141 at main.m:16
I'm not entirely sure how to decipher this. From the guides I've been followed, they say that after including the 'All Exceptions' breakpoint, the thrown exception should be outlined in my source code. If someone could help guide about how to figure out the source of my crash, I would greatly appreciate it!
According to the stack trace, the problem occurs when your view controller attempts to load a nib file.
frame #10: 0x003526f5 UIKit`-[UIViewController _loadViewFromNibNamed:bundle:] + 280
The problem appears to be that the unarchiver is unable to set an outlet configured in the nib file.
frame #6: 0x004eb1f4 UIKit`-[UIRuntimeOutletConnection connect] + 106
To get precise details about the exception, press the debugger's continue button (or type continue, or just c for short, in the console). You may need to do this twice to get all the information.
The exception message should provide you the exact name of the outlet. Perhaps you renamed or deleted a property after you had already set the outlet in Interface Builder. If you inspect the view controller in IB, you should see a yellow warning flag next to any stale outlets. Just click the x to delete.
The reason the debugger appears to stop in main rather than somewhere else is because the exception wasn't thrown in your code, so there's no matching source line for it do display.
I sometimes get a crash deep inside libdispatch with the following backtrace stemming from the SecItemCopyMatching function.
* thread #1: tid = 0x169ee8, 0x0374c830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278, queue = 'com.apple.main-thread, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0374c830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278
frame #1: 0x0374c711 libdispatch.dylib`dispatch_semaphore_wait + 37
frame #2: 0x03921b54 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 231
frame #3: 0x01448e99 Security`securityd_message_with_reply_sync + 78
frame #4: 0x01449098 Security`securityd_send_sync_and_do + 81
frame #5: 0x01459926 Security`__SecItemCopyMatching_block_invoke + 218
frame #6: 0x014589f9 Security`SecOSStatusWith + 37
frame #7: 0x014597da Security`SecItemCopyMatching + 208
frame #8: 0x0022b482 MyApp`+[BITKeychainUtils getPasswordForUsername:andServiceName:error:](self=0x00399e3c, _cmd=0x002d21e0, username=0x003a336c, serviceName=0x0c17c420, error=0xbfffeb24) + 738 at BITKeychainUtils.m:63
frame #9: 0x00221eff MyApp`-[BITHockeyBaseManager stringValueFromKeychainForKey:](self=0x0c1b6400, _cmd=0x002d2322, key=0x003a336c) + 175 at BITHockeyBaseManager.m:297
frame #10: 0x001ef2c2 MyApp`-[BITAuthenticator publicInstallationIdentifier](self=0x0c1b6400, _cmd=0x002d2678) + 194 at BITAuthenticator.m:749
frame #11: 0x00228be1 MyApp`-[BITHockeyManager startManager](self=0x0c6a1e90, _cmd=0x002d2358) + 865 at BITHockeyManager.m:196
frame #12: 0x00090ed4 MyApp`-[ApplicationDelegate init](self=0x0c1850e0, _cmd=0x0375f96b) + 212 at ApplicationDelegate.m:86
frame #13: 0x01583cde UIKit`UIApplicationMain + 1132
frame #14: 0x00002e32 MyApp`main(argc=1, argv=0xbfffee74) + 178 at main.m:15
This crash seems totally random, it never happens to my coworkers. It mainly happens in the 32-bit iOS simulator but it also occurred once on a device.
I have looked at libdispatch source code and I can see that a crash may happen like this: _dispatch_semaphore_wait_slow() → DISPATCH_SEMAPHORE_VERIFY_KR → DISPATCH_CRASH → _dispatch_hardware_crash() → __builtin_trap() but I don’t really understand why that’s happening.
Does anyone know what’s going on?
Edit: the same crash also happened when running unit tests with the following backtrace:
* thread #1: tid = 0x544131, 0x0375a830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278, queue = 'com.apple.main-thread, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0375a830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278
frame #1: 0x0375a711 libdispatch.dylib`dispatch_semaphore_wait + 37
frame #2: 0x0392fb54 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 231
frame #3: 0x0153c20a SystemConfiguration`__SCNetworkReachabilityServer_targetStatus + 234
frame #4: 0x015143ce SystemConfiguration`__SCNetworkReachabilityGetFlags + 415
frame #5: 0x015122a0 SystemConfiguration`reachPerform + 305
frame #6: 0x0344583f CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
frame #7: 0x03445295 CoreFoundation`__CFRunLoopDoSources0 + 437
frame #8: 0x0346229e CoreFoundation`__CFRunLoopRun + 910
frame #9: 0x03461ac3 CoreFoundation`CFRunLoopRunSpecific + 467
frame #10: 0x034618db CoreFoundation`CFRunLoopRunInMode + 123
frame #11: 0x050b79e2 GraphicsServices`GSEventRunModal + 192
frame #12: 0x050b7809 GraphicsServices`GSEventRun + 104
frame #13: 0x01591d3b UIKit`UIApplicationMain + 1225
frame #14: 0x000030ea Test Host`main(argc=10, argv=0xbfffeae0) + 138 at main.m:15
When hitting this type of assertion on x86_64, the rax register contains the error code returned from the kernel syscall.
You should be able to inspect that value from the debugger console via reg read. Detaching the debugger from the process after hitting the exception should also generate a crashreport (which you may want to file).
Unfortunately I don't think the rax trick works on i386 so you may need to retrieve the syscall return value via a breakpoint before hitting the assertion.
In this case the syscall is semaphore_wait and the error is most likely going to be 0xf, i.e. KERN_INVALID_NAME (c.f. /usr/include/mach/kern_return.h)
Hitting that error is an indication of one of the following (in order of likelihood):
over-release/user-after-free of a dispatch semaphore object
heap memory corruption
mach port mismanagement in the process
I've spent a few days trying to track down this issue with no luck so far.
I am trying to measure test coverage in my project, a Mac OS application developed in Objective-C with Xcode, and this means enabling "Instrument Program Flow" and "Generate Test Coverage Files" in the build settings. I believe these correspond to the -fprofile-arcs and -ftest-coverage flags in clang.
When these are enabled (although it seems only -fprofile-arcs affects this issue) the program will crash with an EXC_BAD_ACCESS exception in objc_msgSend in certain places.
When running the application itself, this happens when the first network request is returned. The backtrace contains none of my code, and appears to occur entirely within the Foundation/Cocoa frameworks. While this was annoying, I put up with toggling the build setting on/off depending on whether I was running tests or using the application.
I have now encountered what appears to be the same issue while testing. I have just written a test that includes network access and the tests fail with apparently the same exception in the same location, when instrumenting program flow.
I need to figure out what's causing this. The application I'm developing is for a university project, and one of the goals is to report test coverage and evaluate the testing process. This is quite difficult to do when large parts of the application can't be tested because the tests crash.
* thread #1: tid = 0x2203, 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
frame #0: 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16
frame #1: 0x00007fff88ffe708 Foundation`___NSURLConnectionWillCacheResponse_block_invoke_0 + 110
frame #2: 0x00007fff88e86528 Foundation`__65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 28
frame #3: 0x00007fff88e8646c Foundation`-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 227
frame #4: 0x00007fff88e86368 Foundation`-[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 63
frame #5: 0x00007fff88ffda3c Foundation`_NSURLConnectionWillCacheResponse + 126
frame #6: 0x00007fff879f8272 CFNetwork`___delegate_willCacheResponse_block_invoke_0 + 48
frame #7: 0x00007fff87a75a7a CFNetwork`___withDelegateAsync_block_invoke_0 + 90
frame #8: 0x00007fff87b062ea CFNetwork`__block_global_1 + 28
frame #9: 0x00007fff90110154 CoreFoundation`CFArrayApplyFunction + 68
frame #10: 0x00007fff87a667e4 CFNetwork`RunloopBlockContext::perform() + 124
frame #11: 0x00007fff87a666bb CFNetwork`MultiplexerSource::perform() + 221
frame #12: 0x00007fff900f1b31 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #13: 0x00007fff900f1455 CoreFoundation`__CFRunLoopDoSources0 + 245
frame #14: 0x00007fff901147f5 CoreFoundation`__CFRunLoopRun + 789
frame #15: 0x00007fff901140e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #16: 0x00007fff8a660eb4 HIToolbox`RunCurrentEventLoopInMode + 209
frame #17: 0x00007fff8a660c52 HIToolbox`ReceiveNextEventCommon + 356
frame #18: 0x00007fff8a660ae3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
frame #19: 0x00007fff92804563 AppKit`_DPSNextEvent + 685
frame #20: 0x00007fff92803e22 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
frame #21: 0x00007fff927fb1d3 AppKit`-[NSApplication run] + 517
frame #22: 0x00007fff9279fc06 AppKit`NSApplicationMain + 869
frame #23: 0x0000000100001842 River`main(argc=5, argv=0x00007fff5fbff7b0) + 34 at main.m:13
frame #24: 0x00007fff93aed7e1 libdyld.dylib`start + 1
And here's the backtrace when running the tests:
* thread #1: tid = 0x2503, 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
frame #0: 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16
frame #1: 0x00007fff88ffe708 Foundation`___NSURLConnectionWillCacheResponse_block_invoke_0 + 110
frame #2: 0x00007fff88e86528 Foundation`__65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 28
frame #3: 0x00007fff88e8646c Foundation`-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 227
frame #4: 0x00007fff88e86368 Foundation`-[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 63
frame #5: 0x00007fff88ffda3c Foundation`_NSURLConnectionWillCacheResponse + 126
frame #6: 0x00007fff879f8272 CFNetwork`___delegate_willCacheResponse_block_invoke_0 + 48
frame #7: 0x00007fff87a75a7a CFNetwork`___withDelegateAsync_block_invoke_0 + 90
frame #8: 0x00007fff87b062ea CFNetwork`__block_global_1 + 28
frame #9: 0x00007fff90110154 CoreFoundation`CFArrayApplyFunction + 68
frame #10: 0x00007fff87a667e4 CFNetwork`RunloopBlockContext::perform() + 124
frame #11: 0x00007fff87a666bb CFNetwork`MultiplexerSource::perform() + 221
frame #12: 0x00007fff900f1b31 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #13: 0x00007fff900f1455 CoreFoundation`__CFRunLoopDoSources0 + 245
frame #14: 0x00007fff901147f5 CoreFoundation`__CFRunLoopRun + 789
frame #15: 0x00007fff901140e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #16: 0x00007fff88f03f5e Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 268
frame #17: 0x00007fff88f03e0b Foundation`-[NSRunLoop(NSRunLoop) runUntilDate:] + 78
frame #18: 0x00000001006beba2 RiverTests`runExampleBlock(block=0x00000001020b68b0, name=0x00000001020b6950) + 562 at SPTExampleGroup.m:31
frame #19: 0x00000001006bfd08 RiverTests`__48-[SPTExampleGroup compileExamplesWithNameStack:]_block_invoke(.block_descriptor=0x00000001020b6a50) + 200 at SPTExampleGroup.m:241
frame #20: 0x00000001006c0877 RiverTests`-[SPTSenTestCase SPT_runExampleAtIndex:](self=0x00000001020e04a0, _cmd=0x0000000100519090, index=0) + 423 at SPTSenTestCase.m:61
frame #21: 0x00000001006c0bfd RiverTests`__33+[SPTSenTestCase testInvocations]_block_invoke(.block_descriptor=0x00000001020e03d0) + 61 at SPTSenTestCase.m:82
frame #22: 0x00000001006c142d RiverTests`-[SPTSenTestInvocation invoke](self=0x00000001020e0170, _cmd=0x00007fff9303afa4) + 93 at SPTSenTestInvocation.m:16
frame #23: 0x00000001007d2a05 SenTestingKit`-[SenTestCase invokeTest] + 164
frame #24: 0x00000001007d2b7f SenTestingKit`-[SenTestCase performTest:] + 173
frame #25: 0x00000001006c11ab RiverTests`-[SPTSenTestCase performTest:](self=0x00000001020e04a0, _cmd=0x00000001007d87f4, run=0x000000010055bb30) + 123 at SPTSenTestCase.m:127
frame #26: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #27: 0x00000001007d5dc1 SenTestingKit`-[SenTestSuite performTest:] + 125
frame #28: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #29: 0x00000001007d5dc1 SenTestingKit`-[SenTestSuite performTest:] + 125
frame #30: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #31: 0x00000001007d5dc1 SenTestingKit`-[SenTestSuite performTest:] + 125
frame #32: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #33: 0x00000001007d4b18 SenTestingKit`+[SenTestProbe runTests:] + 134
frame #34: 0x00007fff88edc395 Foundation`__NSFireDelayedPerform + 358
frame #35: 0x00007fff9012f804 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
frame #36: 0x00007fff9012f31d CoreFoundation`__CFRunLoopDoTimer + 557
frame #37: 0x00007fff90114ad9 CoreFoundation`__CFRunLoopRun + 1529
frame #38: 0x00007fff901140e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #39: 0x00007fff8a660eb4 HIToolbox`RunCurrentEventLoopInMode + 209
frame #40: 0x00007fff8a660b94 HIToolbox`ReceiveNextEventCommon + 166
frame #41: 0x00007fff8a660ae3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
frame #42: 0x00007fff92804563 AppKit`_DPSNextEvent + 685
frame #43: 0x00007fff92803e22 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
frame #44: 0x00007fff927fb1d3 AppKit`-[NSApplication run] + 517
frame #45: 0x00007fff9279fc06 AppKit`NSApplicationMain + 869
frame #46: 0x0000000100001842 River`main(argc=8, argv=0x00007fff5fbff6d8) + 34 at main.m:13
frame #47: 0x00007fff93aed7e1 libdyld.dylib`start + 1
The top of these look like the same issue. Is this a problem in my code somewhere (I don't know where it would be) or is there some way to mitigate the issue?
I've tried the typical debugging tips like turning on zombie objects and printing out the contents of the registers when it crashes, neither of those help at all. The registers appear to contain garbage, and having zombies enabled doesn't give any information.
What version of Xcode are you using? I remember seeing something like this when using code coverage with unit tests, but it was fixed in Xcode 4.6. I believe it could be worked around before that by using GCC instead of Clang, but that may or may not be feasible.
From what I can tell, the actual segfault is caused because target->isa is NULL.
To me this suggests memory overwriting. I would try enabling guard malloc (SO question on how to do that) in hopes of catching something writing past the end of a buffer.
I am trying to debug an ipad application I have just inherited from some other developers. At the moment I'm getting a really odd error that I'm not sure how to attack.
The app dies with this error:
* Terminating app due to uncaught exception 'NSGenericException', reason: '* Collection <__NSCFSet: 0xc5d2b40> was mutated while being enumerated.'
When I do po 0xc5d2b40, it tells me that its an array of a certain object type. However when I turn on breakpoints at all exceptions and go through the backtrace, there is no sign of an array of this object type being either enumerated or mutated.
I have seen a few references that suggest that this could be related to coredata and multithreading, but I'm wondering if anyone has any suggestions on how to approach this problem. I should also note: I ONLY get this error on the device, NOT in the simulator.
Thanks in advance!
Note: When the app hits the breakpoint from the objc_exception_throw, using the bt command I get the following results from the various background threads:
Most threads look like this:
tid = 0x2c03, 0x307e9cd4 libsystem_kernel.dylib__workq_kernreturn + 8
frame #0: 0x307e9cd4 libsystem_kernel.dylib__workq_kernreturn + 8
frame #1: 0x32d35f3c libsystem_c.dylib_pthread_wqthread + 616
frame #2: 0x32d35cd0 libsystem_c.dylibstart_wqthread + 8
I have one thread which is running a method in the AFURLConnectionOperation (external library: AFNetworking).
There is a single thread with my code in the backtrace, which is what I referenced above. I'm a bit new to the debugger, am I potentially doing something wrong in checking my backtraces?
The backtrace on the thread where all my code is executing looks like this:
tid = 0x2003, 0x32d2fcac libsystem_c.dylib`OSSpinLockLock$VARIANT$wfe + 84
frame #0: 0x32d2fcac libsystem_c.dylib`OSSpinLockLock$VARIANT$wfe + 84
frame #1: 0x32eb7c88 libobjc.A.dylib`_objc_rootReleaseWasZero_slow + 28
frame #2: 0x32eb5210 libobjc.A.dylib`_objc_rootReleaseWasZero + 132
frame #3: 0x32eb515c libobjc.A.dylib`_objc_rootRelease + 12
frame #4: 0x31ba6b0a CoreData`-[NSSQLIntermediate _generateSQLForKeyPathExpression:allowToMany:inContext:] + 278
frame #5: 0x31ba687a CoreData`-[NSSQLIntermediate _generateSQLForExpression:allowToMany:inContext:] + 186
frame #6: 0x31babea4 CoreData`-[NSSQLSimpleWhereIntermediate _generateSQLType2InContext:] + 660
frame #7: 0x31ba6260 CoreData`-[NSSQLSimpleWhereIntermediate generateSQLStringInContext:] + 400
frame #8: 0x31bbbd06 CoreData`-[NSSQLCompoundWhereIntermediate _generateMulticlauseStringInContext:] + 174
frame #9: 0x31bbba84 CoreData`-[NSSQLCompoundWhereIntermediate generateSQLStringInContext:] + 272
frame #10: 0x31ba5d1a CoreData`-[NSSQLFetchIntermediate generateSQLStringInContext:] + 90
frame #11: 0x31ba24d0 CoreData`-[NSSQLGenerator newSQLStatementForFetchRequest:ignoreInheritance:countOnly:nestingLevel:] + 460
frame #12: 0x31ba2212 CoreData`-[NSSQLAdapter _newSelectStatementWithFetchRequest:ignoreInheritance:] + 414
frame #13: 0x31ba1e6c CoreData`-[NSSQLCore newRowsForFetchPlan:] + 144
frame #14: 0x31ba152e CoreData`-[NSSQLCore objectsForFetchRequest:inContext:] + 698
frame #15: 0x31ba0fc6 CoreData`-[NSSQLCore executeRequest:withContext:error:] + 282
frame #16: 0x31ba0464 CoreData`-[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1432
frame #17: 0x31b9ec28 CoreData`-[NSManagedObjectContext executeFetchRequest:error:] + 604
frame #18: 0x00052956 digidrill`-[DigidrillIncrementalCache executeFetchRequest:allNewerThanOrFailure:] + 410 at DigidrillIncrementalCache.m:80
frame #19: 0x0003fbae digidrill`-[DigidrillIncrementalStore(Responders) immutableCacheListResponderBegin:intoArray:inContext:outErr:] + 434 at DigidrillIncrementalStore+Responders.m:253
frame #20: 0x00015ea4 digidrill`-[DigidrillIncrementalStore executeRequest:withContext:error:] + 3836 at DigidrillIncrementalStore.m:157
frame #21: 0x31ba0464 CoreData`-[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1432
frame #22: 0x31b9ec28 CoreData`-[NSManagedObjectContext executeFetchRequest:error:] + 604
frame #23: 0x00018534 digidrill`+[CoreDataExtractor executeSyncFetchRequest:callback:onDispatchQueue:] + 704 at CoreDataExtractor.m:175
frame #24: 0x0001a9a2 digidrill`+[CoreDataExtractor ensureGammaDataExistsForTrack:maxOld:flags:outErr:] + 1234 at CoreDataExtractor.m:363
frame #25: 0x00058670 digidrill`-[XYGraph dataForTrackPlot:] + 632 at XYGraph.m:230
frame #26: 0x0006f7d6 digidrill`__23-[TrackPlot reloadData]_block_invoke_0 + 66 at TrackPlot.m:49
frame #27: 0x344b0c58 libdispatch.dylib`_dispatch_call_block_and_release + 12
frame #28: 0x344b2d0e libdispatch.dylib`_dispatch_queue_drain + 274
frame #29: 0x344b2b74 libdispatch.dylib`_dispatch_queue_invoke$VARIANT$mp + 40
frame #30: 0x344b37e6 libdispatch.dylib`_dispatch_worker_thread2 + 210
frame #31: 0x32d35dfa libsystem_c.dylib`_pthread_wqthread + 294
frame #32: 0x32d35cd0 libsystem_c.dylib`start_wqthread + 8
This guy has a pretty good explanation that solved it for me:
http://www.pixeldock.com/blog/collection-was-mutated-while-being-enumerated-during-coredata-operation-on-background-thread/
Basically the MO context can only be used by the thread on which it was created.