The link between simulator and xamarin stops after a few seconds (simulator is white) and im able to push the play button again. I use Xamarin.Forms for this iOS project. I've tried this in the newest versions for both Xamarin Studio and Visual Studio.
Native stacktrace:
2017-09-13 14:22:34.113 NewsTestOne.iOS[25106:19993674] critical: 0 NewsTestOne.iOS 0x0000000106847184
mono_handle_native_crash + 244
2017-09-13 14:22:34.113 NewsTestOne.iOS[25106:19993674] critical: 1 NewsTestOne.iOS 0x000000010685320b mono_sigsegv_signal_handler + 171
2017-09-13 14:22:34.114 NewsTestOne.iOS[25106:19993674] critical: 2 libsystem_platform.dylib 0x000000010d451b3a _sigtramp + 26
2017-09-13 14:22:34.114 NewsTestOne.iOS[25106:19993674] critical: 3 ??? 0x0003f78b358d56aa 0x0 + 1116602201101994
2017-09-13 14:22:34.114 NewsTestOne.iOS[25106:19993674] critical: 4 CFNetwork 0x000000010bc51e2e _ZN15TCPIOConnection16_startConnectionEv + 530
2017-09-13 14:22:34.114 NewsTestOne.iOS[25106:19993674] critical: 5 CFNetwork 0x000000010bd8e32a ___ZN4Tube23_onqueue_prepConnectionEU13block_pointerFvvEU13block_pointerFviE_block_invoke.67 + 726
2017-09-13 14:22:34.114 NewsTestOne.iOS[25106:19993674] critical: 6 CFNetwork 0x000000010bd8e807 ___ZN4Tube23_onqueue_prepConnectionEU13block_pointerFvvEU13block_pointerFviE_block_invoke_2.83 + 21
2017-09-13 14:22:34.115 NewsTestOne.iOS[25106:19993674] critical: 7 libdispatch.dylib 0x000000010d0ae585 _dispatch_call_block_and_release + 12
2017-09-13 14:22:34.115 NewsTestOne.iOS[25106:19993674] critical: 8 libdispatch.dylib 0x000000010d0cf792 _dispatch_client_callout + 8
2017-09-13 14:22:34.115 NewsTestOne.iOS[25106:19993674] critical: 9 libdispatch.dylib 0x000000010d0b5237 _dispatch_queue_serial_drain + 1022
2017-09-13 14:22:34.115 NewsTestOne.iOS[25106:19993674] critical: 10 libdispatch.dylib 0x000000010d0b598f _dispatch_queue_invoke + 1053
2017-09-13 14:22:34.115 NewsTestOne.iOS[25106:19993674] critical: 11 libdispatch.dylib 0x000000010d0b7899 _dispatch_root_queue_drain + 813
2017-09-13 14:22:34.116 NewsTestOne.iOS[25106:19993674] critical: 12 libdispatch.dylib 0x000000010d0b750d _dispatch_worker_thread3 + 113
2017-09-13 14:22:34.116 NewsTestOne.iOS[25106:19993674] critical: 13 libsystem_pthread.dylib 0x000000010d4635a2 _pthread_wqthread + 1299
2017-09-13 14:22:34.116 NewsTestOne.iOS[25106:19993674] critical: 14 libsystem_pthread.dylib 0x000000010d46307d start_wqthread + 13
2017-09-13 14:22:34.116 NewsTestOne.iOS[25106:19993674] critical:
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
This usually indicate thread errors on your code, I suggest you debug all your server side calls which are asynchronous, it can be plenty of things like:
A Task.Run method running in a background thread trying to update a UI property.
A Custom Renderer or a Dependency Servicewhich is using within an asynchronous Task.
If you have Timers in your code take a looks at those also.
With the latest versions of Xamarin the debugger is not capable to correctly debug native code so make sure you clean your solution and try to debug on a real device. (also getting rid of break points sometime helps.)
Related
On devices with iOS 13, when calling the GeneXus.SD.Media.Camera.TakePhoto() method for the first time takes about 10 to 15 seconds to continue program execution.
Execution of any other option or button is suspended until the camera control has been shown, otherwise the application stops working.
Note: This behavior only happens the first time GeneXus.SD.Media.Camera.TakePhoto() method is called.
The apparent problem is that Genexus is making a call to a thread in the background without using the following statement:
DispatchQueue.main.async {
//Do UI Code here.
//Call Google maps methods.}
The log that the application shows when it is waiting to show the control of the camera is the following:
Log en XCODE 11.3
Main Thread Checker: UI API called on a background thread: -[UIApplication userInterfaceLayoutDirection]
PID: 268, TID: 5281, Thread name: (none), Queue name: com.apple.camera.zoom-dial-image-generation, QoS: 21
Backtrace:
4 GXUIApplication 0x000000010c674170 $s15GXUIApplicationAAC28userInterfaceLayoutDirectionSo06UIUsercdE0VvgTo + 212
5 UIKitCore 0x000000019fea34fc AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 15566076
6 UIKitCore 0x000000019f6bdc8c AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 7285900
7 UIKitCore 0x000000019f6bda18 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 7285272
8 UIKitCore 0x000000019f64a848 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6813768
9 CameraUI 0x00000001bdfee5a8 91E5E69E-0F28-35E3-86F9-7AA8B1D7F726 + 1369512
10 UIKitCore 0x000000019f63ee94 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6766228
11 UIKitCore 0x000000019f63ecb0 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6765744
12 UIKitCore 0x000000019f63c464 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6755428
13 CameraUI 0x00000001bdfee2c0 91E5E69E-0F28-35E3-86F9-7AA8B1D7F726 + 1368768
14 CameraUI 0x00000001bdfed65c 91E5E69E-0F28-35E3-86F9-7AA8B1D7F726 + 1365596
15 AssetsLibraryServices 0x00000001b0462d3c 31232DEC-0B77-3A8B-B80A-A51A16204F8E + 228668
16 libdispatch.dylib 0x000000010d091e1c _dispatch_call_block_and_release + 32
17 libdispatch.dylib 0x000000010d09327c _dispatch_client_callout + 20
18 libdispatch.dylib 0x000000010d09a90c _dispatch_lane_serial_drain + 720
19 libdispatch.dylib 0x000000010d09b4fc _dispatch_lane_invoke + 408
20 libdispatch.dylib 0x000000010d0a64dc _dispatch_workloop_worker_thread + 1344
21 libsystem_pthread.dylib 0x000000019b62b6d0 _pthread_wqthread + 280
22 libsystem_pthread.dylib 0x000000019b6319e8 start_wqthread + 8
2020-02-03 16:52:16.618996-0500 Routik[268:5281] [reports] Main Thread Checker: UI API called on a background thread: -[UIApplication userInterfaceLayoutDirection]
PID: 268, TID: 5281, Thread name: (none), Queue name: com.apple.camera.zoom-dial-image-generation, QoS: 21
Backtrace:
4 GXUIApplication 0x000000010c674170 $s15GXUIApplicationAAC28userInterfaceLayoutDirectionSo06UIUsercdE0VvgTo + 212
5 UIKitCore 0x000000019fea34fc AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 15566076
6 UIKitCore 0x000000019f6bdc8c AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 7285900
7 UIKitCore 0x000000019f6bda18 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 7285272
8 UIKitCore 0x000000019f64a848 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6813768
9 CameraUI 0x00000001bdfee5a8 91E5E69E-0F28-35E3-86F9-7AA8B1D7F726 + 1369512
10 UIKitCore 0x000000019f63ee94 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6766228
11 UIKitCore 0x000000019f63ecb0 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6765744
12 UIKitCore 0x000000019f63c464 AA897CA9-8D15-3DD7-BB4F-8D90F9A28571 + 6755428
13 CameraUI 0x00000001bdfee2c0 91E5E69E-0F28-35E3-86F9-7AA8B1D7F726 + 1368768
14 CameraUI 0x00000001bdfed65c 91E5E69E-0F28-35E3-86F9-7AA8B1D7F726 + 1365596
15 AssetsLibraryServices 0x00000001b0462d3c 31232DEC-0B77-3A8B-B80A-A51A16204F8E + 228668
16 libdispatch.dylib 0x000000010d091e1c _dispatch_call_block_and_release + 32
17 libdispatch.dylib 0x000000010d09327c _dispatch_client_callout + 20
18 libdispatch.dylib 0x000000010d09a90c _dispatch_lane_serial_drain + 720
19 libdispatch.dylib 0x000000010d09b4fc _dispatch_lane_invoke + 408
20 libdispatch.dylib 0x000000010d0a64dc _dispatch_workloop_worker_thread + 1344
21 libsystem_pthread.dylib 0x000000019b62b6d0 _pthread_wqthread + 280
22 libsystem_pthread.dylib 0x000000019b6319e8 start_wqthread + 8
2020-02-03 16:52:26.217529-0500 Routik[268:5081] [Common] _BSMachError: port fe03; (os/kern) invalid capability (0x14) "Unable to insert COPY_SEND"
Actually, it's a false positive in Apple's Main Thread Checker tool. Let me explain:
Main Thread Checker works by at app launch, dynamically replaces the implementations of methods that should only be called on the main thread with a version that prepends the check. Methods known to be safe for use on background threads are excluded from this check.
The method called from a background thread is -[UIApplication userInterfaceLayoutDirection].
GeneXus applications use a subclass of UIApplication (GXUIApplication) which overrides this method (userInterfaceLayoutDirection) in order to support SetLanguage function of Right to Left languages on Left to Right configured devices at runtime (or the other way around). Inside this override, [super userInterfaceLayoutDirection] is called, and this is where Main Thread Checker raises the warning.
This method is called in the background internally from Apple's frameworks implementations as you can see in the Backtrace you posted, everything except GXUIApplication userInterfaceLayoutDirection method itself is not GeneXus code.
The problem is Main Thread Checker raises the [UIApplication userInterfaceLayoutDirection] call warning only when the call is explicit, and ignored when it's called internally from another Apple framework. In this case, it's considered explicit because the method is overwritten in the subclass even though it's called internally from another Apple framework.
You can check this by replacing in the source file main.m, in the line:
return UIApplicationMain(argc, argv, NSStringFromClass([GXUIApplication class]), NSStringFromClass([GXAppDelegate class]));
with:
return UIApplicationMain(argc, argv, NSStringFromClass([UIApplication class]), NSStringFromClass([GXAppDelegate class]));
With this change (not using the subclass with the override), Main Thread Checker won't raise the warning, even though the same method is still being called internally from a background thread.
We will look for a workaround for this Main Thread Checker issue in the upcoming GeneXus upgrades (thanks for the report) and also notify Apple about the issue with Main Thread Checker.
Meanwhile, you can disable Main Thread Checker from Xcode:
Also, you don't have to worry about this being an issue for your users, as Main Thread Checker is only active when the app is launched from Xcode (with Main Thread Checker diagnostic enabled).
We have built a titanium application which works fine in the Appcelerator, but when we open and built the same in the Xcode, it is throwing an error like could not find the file ti.main.js.
Below are the details of the error, which we are getting in the emulator.
Could not find the file ti.main.js
4 POC 0x000000010f693d8c -[KrollInvocation invoke:] + 124
5 POC 0x000000010f695d97 -[KrollContext
invokeOnThread:method:withObject:callback:selector:] + 199
6 POC 0x000000010f68e254 -[KrollBridge evalFile:callback:selector:] + 116
7 POC 0x000000010f68f1f7 -[KrollBridge didStartNewContext:] + 2935
8 POC 0x000000010f6969cd -[KrollContext main] + 2413
9 Foundation 0x0000000112e77732 __NSThread__start__ + 1221
10 libsystem_pthread.dylib 0x00000001191f4661 _pthread_body + 340
11 libsystem_pthread.dylib 0x00000001191f450d _pthread_body + 0
12 libsystem_pthread.dylib 0x00000001191f3bf9 thread_start + 13
Thanks in advance.
I am using the recent facebook sdk and parse sdk for ios. When i try to run my app on the simulator i get the following error:
ParseStarterProject-Swift[2841:107652] -[PFUserAuthenticationController authenticationDelegateForAuthType:]: unrecognized selector sent to instance 0x7fd0bbc34620
2015-09-30 00:56:33.960 ParseStarterProject-Swift[2841:107652] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PFUserAuthenticationController authenticationDelegateForAuthType:]: unrecognized selector sent to instance 0x7fd0bbc34620'
This error is when i call the facebook application in my appdelegate file.
PFFacebookUtils.initializeFacebookWithApplicationLaunchOptions(launchOptions)
The following is my stack trace.
First throw call stack:
(
0 CoreFoundation 0x00000001102cef65 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x000000011280fdeb objc_exception_throw + 48
2 CoreFoundation 0x00000001102d758d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
3 CoreFoundation 0x0000000110224f7a ___forwarding___ + 970
4 CoreFoundation 0x0000000110224b28 _CF_forwarding_prep_0 + 120
5 ParseStarterProject-Swift 0x000000010f06fdf5 +[PFFacebookUtils _authenticationProvider] + 139
6 ParseStarterProject-Swift 0x000000010f06fe4c +[PFFacebookUtils initializeFacebookWithApplicationLaunchOptions:] + 48
7 ParseStarterProject-Swift 0x000000010ef42f50 _TFC25ParseStarterProject_Swift11AppDelegate11applicationfS0_FTCSo13UIApplication29didFinishLaunchingWithOptionsGSqGVSs10DictionaryCSo8NSObjectPSs9AnyObject____Sb + 2160
8 ParseStarterProject-Swift 0x000000010ef43903 _TToFC25ParseStarterProject_Swift11AppDelegate11applicationfS0_FTCSo13UIApplication29didFinishLaunchingWithOptionsGSqGVSs10DictionaryCSo8NSObjectPSs9AnyObject____Sb + 179
9 UIKit 0x000000011138f4ca -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 272
10 UIKit 0x0000000111390670 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3415
11 UIKit 0x0000000111396e15 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1755
12 UIKit 0x0000000111393ff0 -[UIApplication workspaceDidEndTransaction:] + 188
13 FrontBoardServices 0x0000000113ef37ac -[FBSSerialQueue _performNext] + 192
14 FrontBoardServices 0x0000000113ef3b1a -[FBSSerialQueue _performNextFromRunLoopSource] + 45
15 CoreFoundation 0x00000001101fb0a1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
16 CoreFoundation 0x00000001101f0fcc __CFRunLoopDoSources0 + 556
17 CoreFoundation 0x00000001101f0483 __CFRunLoopRun + 867
18 CoreFoundation 0x00000001101efe98 CFRunLoopRunSpecific + 488
19 UIKit 0x000000011139398d -[UIApplication _run] + 402
20 UIKit 0x0000000111398676 UIApplicationMain + 171
21 ParseStarterProject-Swift 0x000000010ef449dd main + 109
22 libdyld.dylib 0x00000001133e492d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)
I managed to fix this error doing the following:
First I deployed the official version of Parse Server (instead of Rob's version). Open this link and click 'Deploy to Heroku', follow the steps. https://github.com/ParsePlatform/parse-server-example
After that I downloaded the Parse Frameworks (including Facebook framework) from the link below and replaced all current frameworks in my project with these frameworks downloaded. https://parse.com/downloads/ios/parse-library/latest
Other than that just follow the class steps (adding code to AppDelegate, Info.pslist e etc.
Any problems, let me know.
I am occasionally seeing crashes with a stack trace like this:
0 libobjc.A.dylib 0x97dc0edb objc_msgSend + 27
1 com.apple.CoreData 0x97edcdc2 -[_PFManagedObjectReferenceQueue _queueForDealloc:] + 162
2 com.apple.CoreData 0x97edccbe -[NSManagedObject release] + 94
3 com.apple.CoreFoundation 0x9318ef38 CFRelease + 152
4 com.apple.CoreFoundation 0x931a7460 __CFBasicHashStandardCallback + 384
5 com.apple.CoreFoundation 0x931a706e __CFBasicHashDrain + 478
6 com.apple.CoreFoundation 0x9318f101 _CFRelease + 353
7 com.apple.CoreFoundation 0x931bbc6d _CFAutoreleasePoolPop + 253
8 com.apple.Foundation 0x973270aa NSPopAutoreleasePool + 76
9 com.apple.Foundation 0x97326fd2 -[NSAutoreleasePool drain] + 130
10 com.apple.AppKit 0x95087185 -[NSApplication run] + 627
11 com.apple.AppKit 0x9507f2d9 NSApplicationMain + 574
12 com.karelia.Sandvox 0x70001ef6 start + 54
Unfortunately, it's rather random to reproduce. Does anyone have any ideas what could cause such a crash? Doesn't help that no-one seems to have mentioned -_queueForDealloc: on the internet before!
I have a vague memory of a similar problem in the past where this was a symptom of deallocating a managed object while it still had KVO observers attached. Anyone concur?
Having finally been able to reproduce the problem on a development machine, it seems this crash is a side-effect of an earlier exception during context teardown.
The sequence of events is something like:
The MOC is being deallocated, so it's time to tear down its contents
To do so, all registered MOs are turned into faults*
The act of turning a MO into a fault sends KVO-notifications
An observer receives the notification and tries to act upon it, hitting a now invalid MO in the graph
Core Data throws an exception from the invalid access
For reasons unknown, that exception is not passed to my exception reporter
The MOs get released, but the exception left Core Data in an unexpected state, so the MO deallocation crashes
In short the real problem is that observers outlive the context; don't allow them to! Any object observing a MO should probably also have a strong reference to the MOC, like NSObjectController and friends do.
*I found in testing that Core Data often does this on a background thread, presumably to avoid blocking the main thread
MOC – managed object context
MO – managed object
-_queueForDealloc: is an undocumented internal method. It shows up in stacks from time to time but it's nothing we deal with directly.
Your problem is most likely caused by over-releasing a managedObject. A managedObject will be strongly retained by a context that inserts, updates or changes the object so if you micromanage the objects own retention, you can over-release it prior to the context releasing it. This cause the managed object to disappear at seemingly at random. Conversely, you can over-retain causing an object to persist after the context has deleted it.
I encourage people to avoid retaining managed objects but when you do, put them a class property or a collection like an array or set. That way, the retention is handled for you.
We hit into a a similar issue when using a private managed object context inside an NSOperation and we ended up working around it by weakifying any parameters and using a private #autoreleasepool. I'll elaborate further below.
Our current set up has an NSOperationQueue which has a long running calculation we do in the background. The operation first creates a private managed object context with the parent set as the main object context and goes and fetches its objects.
In the mean time, we have a separate NSOperationQueue elsewhere that syncs down new data from our server, potentially adding, updating, or removing objects used by our calculation operation.
We first saw a bunch of these crashes out in the wild and the only way to repro it locally is to have both calculation and sync operations run continuously and after 5-10 minutes, we would see a crash similar to one of the below:
Thread : Crashed: background queue :: NSOperation 0x18f43c90
0 libobjc.A.dylib 0x36f11f46 objc_msgSend + 5
1 CoreData 0x2928408f -[NSManagedObject release] + 166
2 CoreData 0x2927b4d7 -[_PFArray dealloc] + 94
3 libobjc.A.dylib 0x36f201a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 404
4 CoreFoundation 0x294713a9 _CFAutoreleasePoolPop + 16
5 Foundation 0x2a1b6453 -[__NSOperationInternal _start:] + 1058
6 Foundation 0x2a25b44b __NSOQSchedule_f + 186
7 libdispatch.dylib 0x3746d651 _dispatch_queue_drain + 952
8 libdispatch.dylib 0x3746809d _dispatch_queue_invoke + 84
9 libdispatch.dylib 0x3746eba1 _dispatch_root_queue_drain + 320
10 libdispatch.dylib 0x3746fcd7 _dispatch_worker_thread3 + 94
11 libsystem_pthread.dylib 0x375c6e31 _pthread_wqthread + 668
Thread : Crashed: background queue :: NSOperation 0x1db59e80
0 libsystem_kernel.dylib 0x3722edfc __pthread_kill + 8
1 libsystem_pthread.dylib 0x372acd37 pthread_kill + 62
2 libsystem_c.dylib 0x371ce909 abort + 76
3 libsystem_malloc.dylib 0x37258331 szone_size
4 libobjc.A.dylib 0x36bf1621 object_dispose + 20
5 CoreData 0x28ec571d -[_PFManagedObjectReferenceQueue dealloc] + 80
6 CoreData 0x28e5630f -[NSManagedObject dealloc] + 166
7 CoreData 0x28e55217 -[_PFManagedObjectReferenceQueue _queueForDealloc:] + 246
8 CoreData 0x28e5508f -[NSManagedObject release] + 166
9 CoreData 0x28e4c4d7 -[_PFArray dealloc] + 94
10 libobjc.A.dylib 0x36c031a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 404
11 CoreFoundation 0x29042149 _CFAutoreleasePoolPop + 16
12 Foundation 0x29d88c23 -[__NSOperationInternal _start:] + 1058
13 Foundation 0x29e2dc1b __NSOQSchedule_f + 186
14 libdispatch.dylib 0x371505b1 _dispatch_queue_drain + 952
15 libdispatch.dylib 0x3714af85 _dispatch_queue_invoke + 84
16 libdispatch.dylib 0x37151b9b _dispatch_root_queue_drain + 338
17 libdispatch.dylib 0x37152cd7 _dispatch_worker_thread3 + 94
18 libsystem_pthread.dylib 0x372a9e31 _pthread_wqthread + 668
Thread : Crashed: NSOperationQueue Serial Queue
0 libsystem_kernel.dylib 0x396871f0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x396ef7b7 pthread_kill + 58
2 libsystem_c.dylib 0x39637ff9 abort + 76
3 libsystem_malloc.dylib 0x396aed25 szone_size
4 libobjc.A.dylib 0x390d93a9 object_dispose + 20
5 CoreData 0x2e3d4081 -[_PFManagedObjectReferenceQueue dealloc] + 80
6 CoreData 0x2e3655b7 -[NSManagedObject dealloc] + 166
7 CoreData 0x2e364501 -[_PFManagedObjectReferenceQueue _queueForDealloc:] + 244
8 CoreData 0x2e36437d -[NSManagedObject release] + 164
9 CoreData 0x2e35b867 -[_PFArray dealloc] + 94
10 libobjc.A.dylib 0x390e20d3 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
11 CoreFoundation 0x2e5294c1 _CFAutoreleasePoolPop + 16
12 Foundation 0x2ef29999 -[__NSOperationInternal _start:] + 1064
13 Foundation 0x2efcd745 __NSOQSchedule_f + 60
14 libdispatch.dylib 0x395c0cbd _dispatch_queue_drain + 488
15 libdispatch.dylib 0x395bdc6f _dispatch_queue_invoke + 42
16 libdispatch.dylib 0x395c15f1 _dispatch_root_queue_drain + 76
17 libdispatch.dylib 0x395c18dd _dispatch_worker_thread2 + 56
18 libsystem_pthread.dylib 0x396ecc17 _pthread_wqthread + 298
We reviewed the code multiple times and was not able to determine why it was crashing. We tried enabling NSZombies, but would run out of memory long before we could get a repro.
What we ended up doing is the following 2 things:
#autoreleasepool
Inside our [privateObjectContext performBlockAndWait:^{…}] which resides inside our NSOperationBlock, we wrapped all the code inside an #autoreleasepool{…}. That way all NSManagedObjects retrieved during that block of code will be mark for release before leaving the performBlockAndWait.
weakify/strongify
Any parameters that include NSManagedObjects were weakify before passing it into the block, and strongify once in the block. This way since we no longer have a strong reference to them, they can be released if they become out of date while we wait for the NSOperation to start. Here's a good article on how weakify/strongify works: http://aceontech.com/objc/ios/2014/01/10/weakify-a-more-elegant-solution-to-weakself.html
i has another solution so solve that bug. In examples, MOC properties for ARC looks like (readonly,strong,nonatomic)
After weeks of dancing about that time-to-time crash i got solution for osx (just remove nonatomic).
Now it perfect, all crashes go out.
So, when developing, I get a crash when running the app in iPhone simulator. Say something like this in the console...
2010-08-01 19:28:04.228 FakeCreme[32888:207] adding bucket: (null)
2010-08-01 19:28:04.230 FakeCreme[32888:207] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSMutableArray insertObject:atIndex:]: attempt to insert nil object at 0'
*** Call stack at first throw:
(
0 CoreFoundation 0x02641919 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x0278f5de objc_exception_throw + 47
2 CoreFoundation 0x0263b571 -[__NSArrayM insertObject:atIndex:] + 225
3 CoreFoundation 0x026369c4 -[__NSArrayM addObject:] + 68
4 FakeCreme 0x0000b645 -[BucketsTable didReceiveEvents:withVerb:forDomain:] + 557
5 FakeCreme 0x0002e2fa -[EventManager addObject:withVerb:inDomain:] + 3206
6 FakeCreme 0x0000a7a8 -[BucketsTable viewDidLoad] + 1389
7 UIKit 0x003cac26 -[UIViewController view] + 179
8 UIKit 0x003c9050 -[UIViewController contentScrollView] + 42
9 UIKit 0x003d8df7 -[UINavigationController _computeAndApplyScrollContentInsetDeltaForViewController:] + 48
10 UIKit 0x003d74ff -[UINavigationController _layoutViewController:] + 43
11 UIKit 0x003d8789 -[UINavigationController _startTransition:fromViewController:toViewController:] + 524
12 UIKit 0x003d3329 -[UINavigationController _startDeferredTransitionIfNeeded] + 266
13 UIKit 0x004ee209 -[UILayoutContainerView layoutSubviews] + 226
14 QuartzCore 0x040e50d5 -[CALayer layoutSublayers] + 177
15 QuartzCore 0x040e4e05 CALayerLayoutIfNeeded + 220
16 QuartzCore 0x040e464c _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 302
17 QuartzCore 0x040e42b0 _ZN2CA11Transaction6commitEv + 292
18 UIKit 0x0032563f -[UIApplication _reportAppLaunchFinished] + 39
19 UIKit 0x00325a68 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 545
20 UIKit 0x0032f452 -[UIApplication handleEvent:withNewEvent:] + 1958
21 UIKit 0x00328074 -[UIApplication sendEvent:] + 71
22 UIKit 0x0032cac4 _UIApplicationHandleEvent + 7495
23 GraphicsServices 0x02cbbafa PurpleEventCallback + 1578
24 CoreFoundation 0x02622dc4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
25 CoreFoundation 0x02583737 __CFRunLoopDoSource1 + 215
26 CoreFoundation 0x025809c3 __CFRunLoopRun + 979
27 CoreFoundation 0x02580280 CFRunLoopRunSpecific + 208
28 CoreFoundation 0x025801a1 CFRunLoopRunInMode + 97
29 UIKit 0x00325226 -[UIApplication _run] + 625
30 UIKit 0x00330b58 UIApplicationMain + 1160
31 FakeCreme 0x000025a0 main + 102
32 FakeCreme 0x00002531 start + 53
33 ??? 0x00000001 0x0 + 1
)
terminate called after throwing an instance of 'NSException'
(Details of crash don't matter, just an illustration.)
Now, it used to be the case that when I get such a crash, I can run Xcode debugger and get the call trace conveniently loaded there, so that the debugger loads the call stack and I can interactively navigate in the methods that were called just at the time.
But ever since installing Xcode 3.2.3 and/or switching computers, this doesn't work. I load debugger at this point where my app is halted, but it comes up empty, no call stack.
I'm sure there is an Xcode setting I have missed somewhere, but didn't find anything on my own quickly glancing through settings. What do I need to do to get the call stack loaded in debugger at this point?
Sometimes, for some reason the XCode debugger stops in a place where it simply cannot pick up debug values. I've seen it when trying to stop in callbacks for animations. There's not a setting you can really chose to fix this (though you should check you are running in Debugn and not Release, and that debugging symbol generation is still checked in project settings).
You might try using the LLVM debugger in XCode 4.
However, to solve your particular problem - it seems pretty clear you are trying to insert an object into an array in +didReceiveEvents:WithVerb:ForDomain: in BucketsTable, where you are inserting some point too far after the last element in the array. You might try an NSLog around any array insert there with index and object values.