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.
Related
We are facing a bit of a conundrum in our DriverKit extension development. We would like to build and debug on Monterey. This means that we need to use Xcode 13. We also need to support Big Sur. Unfortunately we haven't been able to build a DEXT with Xcode 13 that works on Big Sur.
We are setting the DRIVERKIT_DEPLOYMENT_TARGET to 19 (the lowest possible value). The DEXT loads fine on Big Sur but whenever a user client connects the DEXT process crashes with an assertion failure like this:
Crashed Thread: 0 Dispatch queue: Root
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
dyld2 mode
abort() called
Thread 0 Crashed:: Dispatch queue: Root
0 libsystem_kernel.dylib 0x0000000104bfb3a4 __pthread_kill + 8
1 libsystem_pthread.dylib 0x0000000104de6844 pthread_kill + 272
2 libsystem_c.dylib 0x0000000104b98f24 abort + 124
3 com.apple.DriverKit 0x00000001048b12b4 __assert_rtn + 92
4 com.apple.DriverKit 0x00000001048b151c OSMetaClassBase::QueueForObject(unsigned long long) (.cold.2) + 44
5 com.apple.DriverKit 0x0000000104893068 OSMetaClassBase::QueueForObject(unsigned long long) + 176
6 com.apple.DriverKit 0x0000000104893780 OSMetaClassBase::Invoke(IORPC) + 412
7 com.apple.DriverKit 0x000000010489425c Server(void*, mach_msg_header_t*, mach_msg_header_t*) + 512
8 com.apple.DriverKit 0x00000001048959c8 uiomachchannel(void*, dispatch_mach_reason_t, dispatch_mach_msg_s*, int) + 156
9 libdispatch.dylib 0x0000000104a43b90 _dispatch_mach_msg_invoke + 476
10 libdispatch.dylib 0x0000000104a313ec _dispatch_lane_serial_drain + 308
11 libdispatch.dylib 0x0000000104a448f4 _dispatch_mach_invoke + 464
12 libdispatch.dylib 0x0000000104a313ec _dispatch_lane_serial_drain + 308
13 libdispatch.dylib 0x0000000104a32154 _dispatch_lane_invoke + 456
14 libdispatch.dylib 0x0000000104a33408 _dispatch_workloop_invoke + 1680
15 libdispatch.dylib 0x0000000104a3c9f0 _dispatch_workloop_worker_thread + 764
16 libsystem_pthread.dylib 0x0000000104de75e0 _pthread_wqthread + 276
17 libsystem_pthread.dylib 0x0000000104dee7fc start_wqthread + 8
I've seen a similar problem on the Apple developer forums and the advice seems to be "upgrade to Monterey", which doesn't help much.
I have not been able to locate any meaningful assertion message. I tried digging in the XNU sources to find the failing assert, but did not have any luck.
Has anyone been able to build a DEXT with Xcode 13 that works on Big Sur? Any pointers on what to try are very welcome.
We faced the same issue, Apple suggested to do a seperate release for both Monterey and BigSur, or do two builds and modify the installer to install based on the corresponding OS.
I am trying to set up a new MacBook Pro M1 Max. I have been using the same phone with my previous MBP 2018 Intel.
I installed Xcode 13 for M1. When I plug this iPhone 13 Pro Max into this new MBP and open the device manager I get the error that it can't prepare the device for development.
Another piece of info: I am still able to build and deploy my app to the phone from Xcode on this MBP.
I have received this error from time to time on my old laptop and when that happens I just restart the phone and it will work. I tried that with this laptop and that didn't change anything. I don't know if it is exactly the same error as before though.
Here are the details from the error:
Details
Failed to prepare device for development.
Domain: com.apple.dtdevicekit
Code: 806
Recovery Suggestion: If you are certain that Xcode supports development on this device, try disconnecting and reconnecting the device.
User Info: {
AssociatedMobileDeviceFunction = AMDeviceMountImage;
DVTDeviceErrorIsProxied = 1;
DVTRadarComponentKey = 487927;
NSLocalizedFailure = "This operation can fail if the version of the OS on the device is newer than the version of Xcode that is running.";
}
--
The device rejected the pairing attempt.
Domain: com.apple.dt.MobileDeviceErrorDomain
Code: -402653035
User Info: {
DVTRadarComponentKey = 261622;
MobileDeviceErrorCode = "(0xE8000095)";
"com.apple.dtdevicekit.stacktrace" = (
0 DTDeviceKitBase 0x000000017b3c2ff8 DTDKCreateNSErrorFromAMDErrorCode + 272
1 DTDeviceKitBase 0x000000017b3fc3bc -[DTDKMobileDeviceToken _mountDeveloperDiskImage:withError:] + 912
2 DTDeviceKitBase 0x000000017b3fcdb0 __58-[DTDKMobileDeviceToken mountDeveloperDiskImageWithError:]_block_invoke + 564
3 libdispatch.dylib 0x00000001a4b7ebac _dispatch_client_callout + 20
4 libdispatch.dylib 0x00000001a4b8de00 _dispatch_lane_barrier_sync_invoke_and_complete + 56
5 DTDeviceKitBase 0x000000017b3fcb20 -[DTDKMobileDeviceToken mountDeveloperDiskImageWithError:] + 168
6 IDEiOSSupportCore 0x000000017b2a5850 __43-[DVTiOSDevice prepareProxiedDevicesAsync:]_block_invoke + 584
7 DVTFoundation 0x0000000101da6238 __DVT_CALLING_CLIENT_BLOCK__ + 16
8 DVTFoundation 0x0000000101da7824 __DVTDispatchAsync_block_invoke + 564
9 libdispatch.dylib 0x00000001a4b7ce60 _dispatch_call_block_and_release + 32
10 libdispatch.dylib 0x00000001a4b7ebac _dispatch_client_callout + 20
11 libdispatch.dylib 0x00000001a4b86330 _dispatch_lane_serial_drain + 672
12 libdispatch.dylib 0x00000001a4b86ea4 _dispatch_lane_invoke + 392
13 libdispatch.dylib 0x00000001a4b91708 _dispatch_workloop_worker_thread + 656
14 libsystem_pthread.dylib 0x00000001a4d395b0 _pthread_wqthread + 288
15 libsystem_pthread.dylib 0x00000001a4d382c4 start_wqthread + 8
);
}
--
System Information
macOS Version 12.0.1 (Build 21A559)
Xcode 13.1 (19466) (Build 13A1030d)
Timestamp: 2021-11-13T16:59:37-07:00```
As I'm using BugSense, lately I've noticed the following in the stacktrace:
0 libobjc.A.dylib 0x36e0067a 0x36de0000 + 132730
1 Application -[SPLJSONModel toJSONStringWithKeys:] (in Application) (SPLJSONModel.m:1043)
2 Application -[MintRequestWorker sendGnip:completionBlock:] (in Application) (MintRequestWorker.m:370)
3 Application -[MintRequestJsonSerializer serializeEventToJsonForGnipWithAppEnvironment:] (in Application) (MintRequestJsonSerializer.m:56)
4 Application __58-[MintRequestWorker closeSessionAsyncWithCompletionBlock:]_block_invoke (in Application) (MintRequestWorker.m:539)
5 libdispatch.dylib 0x3750bbeb 0x37509000 + 11243
6 libdispatch.dylib 0x3751a9b1 0x37509000 + 72113
7 libdispatch.dylib 0x3751a395 0x37509000 + 70549
8 libsystem_pthread.dylib 0x376c5b29 0x376c4000 + 6953
9 libsystem_pthread.dylib 0x376c5718 0x376c4000 + 5912
And a quite similar error below:
0 libsystem_kernel.dylib 0x19b19b1e0 0x19b180000 + 111072
1 libsystem_c.dylib 0x19b10eb78 0x19b0ac000 + 404344
2 Application -[PLCrashReporter generateLiveReportWithThread:] (in Application) + 0
3 CoreFoundation 0x185db12e4 0x185c8c000 + 1200868
Apparently, BugSense itself is causing an error.
Any similar experience so far? What could be the cause of this? I'm at most suspicious about the framework.
Thanks in advance for your hints!
On the Build Settings tab under Linking, find Other Linker Flags and add "-ObjC" and "-all_load".
Splunk Mint Documentation
I had my iOS App up to 98% completed on Xcode 4.6 and iOS 6.1 and it's working OK.
But then problems begin when I try to update my Xcode to version 5 and the SDK to iOS 7.
When I try to run the app on Xcode 5 but with iOS 6.1 it continues working ok, but when I tried to run on SDK 7 I have these issues:
2013-12-17 19:44:47.656 myAPP[2207:70b] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<MKUserLocation 0x9d9af90> valueForUndefinedKey:]: this class is not key value coding-compliant for the key distanceAnnotation.'
*** First throw call stack:
(
0 CoreFoundation 0x01bf65e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x019798b6 objc_exception_throw + 44
2 CoreFoundation 0x01c866a1 -[NSException raise] + 17
3 Foundation 0x0142d8ca -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 282
4 Foundation 0x0139a921 _NSGetUsingKeyValueGetter + 81
5 Foundation 0x01399f5b -[NSObject(NSKeyValueCoding) valueForKey:] + 260
6 Foundation 0x013b9a5a -[NSObject(NSKeyValueCoding) valueForKeyPath:] + 409
7 Foundation 0x013c68c6 _sortedObjectsUsingDescriptors + 380
8 Foundation 0x013c66d7 -[NSMutableArray(NSKeyValueSorting) sortUsingDescriptors:] + 578
9 myapp
0x00009e50 -[mapa mapViewDidFinishLoadingMap:] + 496
10 MapKit 0x0037e974 -[MKMapView mapViewDidFinishLoadingTiles:] + 78
11 VectorKit 0x050a3ade -[VKMapView mapDidFinishLoadingTiles:] + 78
12 VectorKit 0x050abe4e -[VKMapCanvas mapModelDidFinishLoadingTiles:] + 46
13 VectorKit 0x050b82cd -[VKMapModel didStopLoadingTilesWithError:] + 77
14 VectorKit 0x051ae2e1 -[VKTileProvider didStopLoadingTilesWithError:] + 49
15 VectorKit 0x051b1c99 -[VKTileSource didFinishWithNetwork] + 73
16 VectorKit 0x051c3aa3 __41-[VKResourcesTileSource performDownload:]_block_invoke73 + 51
17 GeoServices 0x04bb98a6 ___ZNK49-[GEOTileLoaderInternal _loadedTile:forKey:info:]66__49-[GEOTileLoaderInternal _loadedTile:forKey:info:]_block_invoke3$_1clERKN8LoadItem9RequesterE_block_invoke_2 + 85
18 libdispatch.dylib 0x021f77f8 _dispatch_call_block_and_release + 15
19 libdispatch.dylib 0x0220c4b0 _dispatch_client_callout + 14
20 libdispatch.dylib 0x021fa75e _dispatch_main_queue_callback_4CF + 340
21 CoreFoundation 0x01c5ba5e __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
22 CoreFoundation 0x01b9c6bb __CFRunLoopRun + 1963
23 CoreFoundation 0x01b9bac3 CFRunLoopRunSpecific + 467
24 CoreFoundation 0x01b9b8db CFRunLoopRunInMode + 123
25 GraphicsServices 0x033579e2 GSEventRunModal + 192
26 GraphicsServices 0x03357809 GSEventRun + 104
27 UIKit 0x004dad3b UIApplicationMain + 1225
28 FarmValencia 0x000029ad main + 141
29 libdyld.dylib 0x0249e70d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Theres simply not enough information to correctly debug this item.
I can recommend however that you add a Breakpoint for all Exceptions
Here is an example of adding an All Exception breakpoint in XCode 4. The process is the same in XCode 5
http://www.alauda.ro/2013/02/03/xcode-4-exception-breakpoints/
Aside from that you may try working with NSSetUncaughtExceptionHandler
http://www.cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
This will allow you to trap the error and output the results but bear in mind that this is something you should only do during debug.
Wrapping it in an "#if DEBUG" is a good idea.
I hope this helps you out. These kind of bugs are a pain to fix.
NOTE
You may check if the key value set you are using didn't change between SDK's
Are you by chance sending the message valueForUndefinedKey: to the class MKUserLocation?
Here's what the class reference says about getting user location:
"The MKUserLocation class defines a specific type of annotation that identifies the user’s current location. You do not create instances of this class directly. Instead, you retrieve an existing MKUserLocation object from the userLocation property of the map view displayed in your application."
https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKUserLocation_Class/Reference/Reference.html
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.