What does this stack trace indicate? Crash caused by Xamarin.Media.MediaPicker.TakePhotoAsync on iOS8 on iPad2
I've logged a bug at... https://bugzilla.xamarin.com/show_bug.cgi?id=22853
But I'd like to make sure that it is not something I'm doing. It works fine on iOS7.
OS Version: iOS 8.0 (12A365)
Report Version: 105
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000002c
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3ab05dfc __pthread_kill + 8
1 libsystem_pthread.dylib 0x3ab85d0e pthread_kill + 58
2 libsystem_c.dylib 0x3aaa5934 abort + 72
3 TouchContainer 0x00bd5b3a mono_handle_native_sigsegv (mini-exceptions.c:2360)
4 TouchContainer 0x00bdef72 mono_sigsegv_signal_handler (mini.c:6868)
5 libsystem_platform.dylib 0x3ab800a0 _sigtramp + 40
6 UIKit 0x30212304 _UIViewTopDownSubtreeTraversal + 260
7 UIKit 0x30212304 _UIViewTopDownSubtreeTraversal + 260
8 UIKit 0x305ab842 -[UIView(UIConstraintBasedLayout_EngineDelegate) _invalidateSystemLayoutSizeFittingSizeAtEngineDelegateLevel] + 118
9 UIKit 0x300429c0 -[UIView(AdditionalLayoutSupport) _setNeedsUpdateConstraintsNeedingLayout:] + 68
10 UIKit 0x305aa4e2 -[UIView(AdditionalLayoutSupport) _setSubviewWantsAutolayoutTripWantsAutolayout:] + 206
11 UIKit 0x2ff88588 -[UIView(Internal) _addSubview:positioned:relativeTo:] + 1352
12 UIKit 0x2ff88032 -[UIView(Hierarchy) addSubview:] + 26
13 UIKit 0x3024b2a2 __56-[UIPresentationController _transplantView:toSuperview:]_block_invoke + 242
14 UIKit 0x3024af8c -[UIPresentationController _performBlockWithoutTriggeringResponderEvents:] + 96
15 UIKit 0x3024b1a6 -[UIPresentationController _transplantView:toSuperview:] + 78
16 UIKit 0x3024e474 __71-[UIPresentationController _initViewHierarchyForPresentationSuperview:]_block_invoke + 768
17 UIKit 0x3024d358 __56-[UIPresentationController runTransitionForCurrentState]_block_invoke + 148
18 UIKit 0x2fffb916 _applyBlockToCFArrayCopiedToStack + 306
19 UIKit 0x2ff777da _afterCACommitHandler + 454
20 CoreFoundation 0x2caca842 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 18
21 CoreFoundation 0x2cac7f24 __CFRunLoopDoObservers + 272
22 CoreFoundation 0x2cac8326 __CFRunLoopRun + 910
23 CoreFoundation 0x2ca15dac CFRunLoopRunSpecific + 472
24 CoreFoundation 0x2ca15bbe CFRunLoopRunInMode + 102
25 GraphicsServices 0x33d4904c GSEventRunModal + 132
26 UIKit 0x2ffe0efc UIApplicationMain + 1436
27 TouchContainer 0x001d81ec wrapper_managed_to_native_MonoTouch_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr + 268
28 TouchContainer 0x0018533c MonoTouch_UIKit_UIApplication_Main_string___intptr_intptr (UIApplication.cs:122)
29 TouchContainer 0x001852fc MonoTouch_UIKit_UIApplication_Main_string___string_string (UIApplication.cs:88)
30 TouchContainer 0x000ad800 Touch_Container_Application_Main_string__ (MainClass.cs:84)
31 TouchContainer 0x0036e9b4 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 196
32 TouchContainer 0x00be115c mono_jit_runtime_invoke (mini.c:6730)
33 TouchContainer 0x00c2059a mono_runtime_invoke (object.c:2831)
34 TouchContainer 0x00c242a2 mono_runtime_exec_main (object.c:4088)
35 TouchContainer 0x00c240ea mono_runtime_run_main (object.c:3714)
36 TouchContainer 0x00bcea74 mono_jit_exec (driver.g.c:1009)
37 TouchContainer 0x00c59894 monotouch_main (monotouch-main.m:469)
38 TouchContainer 0x00bb0da0 main (main.armv7.m:65)
39 TouchContainer 0x000a9024 start + 36
It seems that what I was doing wrong was calling TakePhotoAsync from the Clicked event of an ActionSheet. The action sheet was still presented when the photo picker was presented. Pre iOS8 there must have been defensive code to silently work in this apparently illegal situation. The solution was to run the TakePhotoAsync in a BeginInvokeOnMainThread call. This queues the call on the main thread and allows the ActionSheet some space to finish closing.
User contributions licensed under CC BY-SA 3.0