ios app strange crash on start - ios

My project, called OBI, works fine when launched from Xcode, but when I create .ipa file its crashes with provided log.
In project no classes with names: Mutex, DelayedPointerDeletionManager or MemoryManager, so I can't understood from where this exception.
Thread 0 Crashed:
0 libsystem_pthread.dylib 0x396b7046 _pthread_mutex_check_init + 14
1 libsystem_pthread.dylib 0x396b6e32 _pthread_mutex_lock + 22
2 OBI 0x02a74f20 Mutex::Lock() (Mutex.cpp:152)
3 OBI 0x02838930 DelayedPointerDeletionManager::AddPointerToMainThreadDealloc(void*, MemLabelId) (Mutex.h:32)
4 OBI 0x028384a4 MemoryManager::Deallocate(void*, MemLabelId) (MemoryManager.cpp:1082)
5 OBI 0x028384e4 operator delete[](void*) (MemoryManager.cpp:114)
6 OBI 0x01d28010 std::locale::locale<boost::filesystem::detail::utf8_codecvt_facet>(std::locale const&, boost::filesystem::detail::utf8_codecvt_facet*) (locale_classes.h:581)
7 OBI 0x01d281c4 ___lldb_unnamed_function148423$$OBI + 232
8 dyld 0x2be5b59e ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 174
9 dyld 0x2be5b6ac ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 16
10 dyld 0x2be58d34 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 356
11 dyld 0x2be58b88 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 36
12 dyld 0x2be4fd38 dyld::initializeMainExecutable() + 164
13 dyld 0x2be52ab4 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 1748
14 dyld 0x2be4f22a dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 346
15 dyld 0x2be4f064 _dyld_start + 60
Edit, few lines from console.
Oct 16 14:43:18 Sergiys-iPad kernel[0] <Debug>: launchd[9526] Container: /private/var/mobile/Applications/AA46736B-6348-42BA-A8F0-DD63DC535AF6 (sandbox)
Oct 16 14:43:19 Sergiys-iPad ReportCrash[9527] <Notice>: ReportCrash acting against PID 9526
Oct 16 14:43:19 Sergiys-iPad ReportCrash[9527] <Notice>: Formulating crash report for process OBI[9526]
Oct 16 14:43:19 Sergiys-iPad com.apple.launchd[1] (UIKitApplication:com.mycompany.OBIQA[0x14dc][9526]) <Warning>: (UIKitApplication:com.mycompany.OBIQA[0x14dc]) Job appears to have crashed: Segmentation fault: 11
Oct 16 14:43:19 Sergiys-iPad com.apple.launchd[1] (UIKitApplication:com.mycompany.OBIQA[0x14dc]) <Notice>: (UIKitApplication:com.mycompany.OBIQA[0x14dc]) Throttling respawn: Will start in 2147483647 seconds
Oct 16 14:43:19 Sergiys-iPad backboardd[28] <Warning>: Application 'UIKitApplication:com.mycompany.OBIQA[0x14dc]' exited abnormally with signal 11: Segmentation fault: 11
Oct 16 14:43:19 Sergiys-iPad SpringBoard[33] <Warning>: Application 'com.mycompany.OBIQA' has failed to launch too many times. Not relaunching.
Oct 16 14:43:19 Sergiys-iPad ReportCrash[9527] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/OBI_2013-10-16-144319_Sergiys-iPad.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
I will be very pleased for any help, or direction to dig
EDIT
Finally I found what causes this exception. Is symbol striping option in build setting, after I changed it from all symbols to debug symbols everything become fine.

This is crashing in the dynamic loader as iOS loads your classes into memory. Part of this process is calling +load on any classes that implement the method.
One possibility is that you are doing too much work in +load, and are being killed with a "Failed to launch in time". Providing the full crash log would show whether this is the case.

ImageLoader is linked to the loading of code pieces (external framework, libraries). You should make sure you all those are "see-able" by your binary. Building in XCode can put all in the same folder so you have no path issue but, an din particularly if you are referencing third parties framework you need to make sure they can be "seen" by the main executable. Does the console spit anything?

From what I can see (it would help if you show some code, especially your applicationDidFinishLaunching method) it looks like your app is taking too long to launch and is being killed by the OS.
An app has a certain time limit to set up a root view controller and do any basic set up. if it takes too long, the OS considers it non responsive and kills it. You won't notice this problem when launching from Xcode because the time limit is disabled when launching with a debugger attached: see here https://developer.apple.com/library/ios/qa/qa1592/_index.html
If you are downloading an image in your app delegate I would suggest switching to an asynchronous approach, and also probably handling the image loading from the view controller which will use the image
edit: it looks like you get a different error from the console than the Q&A describes, but without any code I can't help much more than that

Related

React Native ios app crashes when run outside of xcode with failed to scene-create after 19.88s error

My react native app is crashing when launched outside of Xcode with the following exception showing up in the crash report on the device logs for thread 0.
Incident Identifier: DB5E0F81-977F-44B0-BD8B-FAAF33F98119
CrashReporter Key: e3b8d0751b47b37db0d7d6fcc5dde46051f8d30c
Hardware Model: iPhone7,1
Process: crashTest [388]
Path: /var/mobile/Containers/Bundle/Application/CE56E818-7288-4A39-8220-16E17158C916/crashTest.app/crashTest
Identifier: org.reactjs.native.example.crashTest
Version: 1 (1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
Date/Time: 2017-04-25 12:42:30.30 -0400
Launch Time: 2017-04-25 12:42:10.10 -0400
OS Version: iOS 9.1 (13B143)
Report Version: 105
Exception Type: 00000020
Exception Codes: 0x000000008badf00d
Exception Note: SIMULATED (this is NOT a crash)
Highlighted by Thread: 0
Application Specific Information:
org.reactjs.native.example.crashTest failed to scene-create after 19.92s (launch took 0.08s of total time limit 20.00s)
Elapsed total CPU time (seconds): 9.230 (user 9.230, system 0.000), 23% CPU
Elapsed application CPU time (seconds): 0.113, 0% CPU
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x0000000199ff0a7c semaphore_wait_trap + 8
1 libdispatch.dylib 0x0000000199ece614 _dispatch_semaphore_wait_slow + 244
2 CFNetwork 0x0000000184246ac0 CFURLConnectionSendSynchronousRequest + 288
3 CFNetwork 0x000000018426a07c +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 120
4 crashTest 0x0000000100128858 -[RCTBundleURLProvider isPackagerRunning:] (RCTBundleURLProvider.m:76)
5 crashTest 0x0000000100128b00 -[RCTBundleURLProvider guessPackagerHost] (RCTBundleURLProvider.m:92)
6 crashTest 0x0000000100128d10 -[RCTBundleURLProvider packagerServerHost] (RCTBundleURLProvider.m:106)
7 crashTest 0x0000000100128ed4 -[RCTBundleURLProvider jsBundleURLForBundleRoot:fallbackResource:] (RCTBundleURLProvider.m:123)
8 crashTest 0x000000010006a8cc -[AppDelegate application:didFinishLaunchingWithOptions:] (AppDelegate.m:21)
9 UIKit 0x000000018a0f5324 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 400
10 UIKit 0x000000018a323acc -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2904
11 UIKit 0x000000018a327e0c -[UIApplication _runWithMainScene:transitionContext:completion:] + 1656
12 UIKit 0x000000018a324f50 -[UIApplication workspaceDidEndTransaction:] + 168
13 FrontBoardServices 0x000000018e90b7c4 -[FBSSerialQueue _performNext] + 184
14 FrontBoardServices 0x000000018e90bb44 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
15 CoreFoundation 0x0000000184aa4544 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
16 CoreFoundation 0x0000000184aa3fd8 __CFRunLoopDoSources0 + 540
17 CoreFoundation 0x0000000184aa1cd8 __CFRunLoopRun + 724
18 CoreFoundation 0x00000001849d0ca0 CFRunLoopRunSpecific + 384
19 UIKit 0x000000018a0ee1c8 -[UIApplication _run] + 460
20 UIKit 0x000000018a0e8ffc UIApplicationMain + 204
21 crashTest 0x000000010006ad08 main (main.m:16)
22 libdyld.dylib 0x0000000199eee8b8 start + 4
I understand that my app is taking too long to launch and display. If I run directly from Xcode with my device tethered there are no issues (but it does take forever to launch)
I am testing this with the default react project produced with react-native init
When I build the project in Xcode I see the following warning:
[tid:com.facebook.react.JavaScript][RCTModuleData.mm:220] RCTBridge required dispatch_sync to load RCTDevSettings. This may lead to deadlocks
I am new to react-native, and I am assuming maybe this is running in some sort of dev mode that does not allow me to launch the app when un-tethered or on a different network? Are there special instructions I am missing that I need to follow when building the app to run independently on the device without having to archive the app in Xcode?
Check if you're connected to the same WiFi network. Just had this.
In your -[AppDelegate application:didFinishLaunchingWithOptions:] function you're kicking off a synchronous network request, and that request appears to be taking too long. iOS kills your app because it has failed to finish launching (specifically, it's failed to return from application:didFinishLaunchingWithOptions:) after 20 seconds.
I've run into the same issue, and don't have a solution, but a temporary workaround that helped me. I've posted it here - https://github.com/facebook/react-native/issues/10187 in the hopes that someone better versed with objective-c and url loading will take a look and put in the proper fix. Hope this helps. Thanks.
The issue, as Aaron Golden has pointed out, is that a synchronous request is made from the main thread at load time in order to figure out whether the react packager (remote server running on the same network) is accessible. This can take awhile for reasons beyond my knowledge (if someone can expound on this, I'd be grateful), but apple will crash the app if this takes longer than 19 seconds (approx).

iOS 9 GPU crash: gpus_ReturnGuiltyForHardwareRestart

I'm getting a crash periodically with a gpus_ReturnGuiltyForHardwareRestart.
The crash is sporadic, and occurs in a complex multi-threaded app. Sample stack trace below.
It seems to occur (which is rare) when the UI and related handlers are being stressed (think hyperactive user making lots of gestures as quickly as the app and system will allow), with lots of resulting calls to behind-the-scenes and up-front rendering.
Researching gpus_ReturnGuiltyForHardwareRestart suggests this may be due to a buffer issue, e.g. a buffer overrun due to an incorect binding or failure to unbind.
gpus_ReturnGuiltyForHardwareRestart crash
(not relevant, but I did look: gpus_ReturnGuiltyForHardwareRestart)
My understanding is that a buffer gets corrupted in some way, and the crash happens sometime later when the corrupted buffer is accessed.
I've been through the code and made sure every bound buffer and texture is subsequently unbound to prevent unwanted/unintentional changes by later code; still getting the crash.
I did just come across these, suggesting the possibility of a bug in the OS:
iOS 9 Beta 4 crash: gpus_ReturnGuiltyForHardwareRestart (original poster indicated was fixed in 9 beta 5)
Re: OpenGLES driver crash in iOS9 Beta2/3
However, I'm currently testing on 9.3.4, so it seems this would be fixed.I've tried making sure all buffers are properly unbound after use, and tried periodic use of glFlush(), both without success.
Does anybody have experience with this, any knowledge on potential sources, means of tracking down causes, or fixes?
Stack trace:
Date/Time: 2016-08-11T20:20:40Z
Launch Time: 2016-08-11T20:15:22Z
OS Version: iPhone OS 9.3.4 (13G35)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x1
Crashed Thread: 0
Thread 0 Crashed:
0 libGPUSupportMercury.dylib 0x0000000191bd9f28 gpus_ReturnGuiltyForHardwareRestart + 12
1 libGPUSupportMercury.dylib 0x0000000191bdaec4 gpusSubmitDataBuffers + 168
2 GLEngine 0x0000000195e9f1e4 gliPresentViewES_Exec + 172
3 GLEngine 0x0000000195e9f0fc gliPresentViewES + 80
4 OpenGLES 0x000000018576bc44 -[EAGLContext presentRenderbuffer:] + 68
5 NWFPApp 0x00000001001ef8fc -[NWFPIOSGLView renderNormalBuffers] (NWFPIOSGLView.mm:543)
6 NWFPApp 0x00000001001ef814 -[NWFPIOSGLView renderAll] (NWFPIOSGLView.mm:516)
7 NWFPApp 0x00000001001ee780 -[NWFPIOSGLView doInContext:] (NWFPIOSGLView.mm:135)
8 NWFPApp 0x00000001001ef770 -[NWFPIOSGLView drawView] (NWFPIOSGLView.mm:494)
9 NWFPApp 0x0000000100203cc8 -[NWFPGLChoreographer displayLinkEvent:] (NWFPGLChoreographer.m:128)
10 QuartzCore 0x000000018614022c CA::Display::DisplayLinkItem::dispatch() + 36
11 QuartzCore 0x00000001861400e0 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 420
12 IOKit 0x0000000183885e54 IODispatchCalloutFromCFMessage + 368
13 CoreFoundation 0x00000001835ad030 __CFMachPortPerform + 176
14 CoreFoundation 0x00000001835c57d4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
15 CoreFoundation 0x00000001835c4f0c __CFRunLoopDoSource1 + 432
16 CoreFoundation 0x00000001835c2c64 __CFRunLoopRun + 1796
17 CoreFoundation 0x00000001834ecc50 CFRunLoopRunSpecific + 380
18 GraphicsServices 0x0000000184dd4088 GSEventRunModal + 176
19 UIKit 0x00000001887ce088 UIApplicationMain + 200
20 NWFPApp 0x00000001002af1a0 main (main.m:30)
21 ??? 0x000000018308a8b8 0x0 + 0

Swift WHOLE_MODULE_OPTIMIZATION improves compile time, but causes lldb/Xcode crash

TL;DR
Before
SWIFT_WHOLE_MODULE_OPTIMIZATION = NO
Debug compile takes 10-15 minutes
Release compile takes 25+ minutes
po works fine in LLDB
After
SWIFT_WHOLE_MODULE_OPTIMIZATION = YES
Debug compile takes 1-2 minutes
Release compile takes ~8 minutes
po always causes Xcode to crash
Any idea why the horrible compile times based on this info, and/or why Xcode might be crashing?
Deets
I'm working on a large 100% Swift project (there are 3rd party libraries in Objective-C, but all our code is Swift). We have been having atrocious compile times, usually around 10-15 minutes to compile the debug configuration and 30+ minutes to compile the release configuration.
This project has been very difficult to work with because of the horrible compile times. I've been searching for ways to improve this, particularly through build settings and for months had no luck. One thing I overlooked was SWIFT_WHOLE_MODULE_OPTIMIZATION, particularly because any mention of it claims it will increase a project's compile time.
So the other day we enabled SWIFT_WHOLE_MODULE_OPTIMIZATION and lo and behold we have a 10x improvement on compile times.
The problem is, now whenever we're debugging the project and try printing an object in lldb with po myObject Xcode immediately crashes. Here's some info from the crash log:
Process: Xcode [5860]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 6.4 (7720)
Build Info: IDEFrameworks-7720000000000000~8
App Item ID: 497799835
App External ID: 812725084
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Xcode [5860]
Date/Time: 2015-08-05 15:53:08.265 -0600
OS Version: Mac OS X 10.11 (15A235d)
Report Version: 11
Time Awake Since Boot: 13000 seconds
Crashed Thread: 20
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000008f
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x8f:
-->
__TEXT 000000010ef62000-000000010ef63000 [ 4K] r-x/rwx SM=COW /Applications/Xcode.app/Contents/MacOS/Xcode
Application Specific Information:
ProductBuildVersion: 6E35b
Here's the stack trace on the crashed thread:
Thread 20 Crashed:: <DBGLLDBSessionThread (pid=6402)>
0 com.apple.LLDB.framework 0x0000000116b09ab4 swift::ArchetypeBuilder::resolveArchetype(swift::Type) + 68
1 com.apple.LLDB.framework 0x0000000116b0f808 std::__1::__function::__func<substConcreteTypesForDependentTypes(swift::ArchetypeBuilder&, swift::Type)::$_6, std::__1::allocator<substConcreteTypesForDependentTypes(swift::ArchetypeBuilder&, swift::Type)::$_6>, swift::Type (swift::Type)>::operator()(swift::Type&&) + 152
2 com.apple.LLDB.framework 0x0000000116bc0986 swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 54
3 com.apple.LLDB.framework 0x0000000116bc0f2b swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 1499
4 com.apple.LLDB.framework 0x0000000116bc0bbb swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 619
5 com.apple.LLDB.framework 0x0000000116bc0c0a swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 698
6 com.apple.LLDB.framework 0x0000000116b0c8f2 swift::ArchetypeBuilder::substDependentType(swift::Type) + 50
7 com.apple.LLDB.framework 0x0000000116e9554e (anonymous namespace)::LowerType::visitAnyStructType(swift::CanType, swift::StructDecl*) + 270
8 com.apple.LLDB.framework 0x0000000116e92e66 swift::Lowering::TypeConverter::getTypeLoweringForUncachedLoweredType(swift::Lowering::TypeConverter::TypeKey) + 150
9 com.apple.LLDB.framework 0x0000000116e92b39 swift::Lowering::TypeConverter::getTypeLowering(swift::Lowering::AbstractionPattern, swift::Type, unsigned int) + 2361
10 com.apple.LLDB.framework 0x0000000116f8f711 lldb_private::SwiftSILManipulator::emitLValueForVariable(swift::VarDecl*, lldb_private::SwiftExpressionParser::SILVariableInfo&) + 1521
11 com.apple.LLDB.framework 0x00000001172ac7ee (anonymous namespace)::LLDBNameLookup::emitLValueForVariable(swift::VarDecl*, swift::SILBuilder&) + 102
12 com.apple.LLDB.framework 0x0000000116ebb162 swift::Lowering::SILGenFunction::emitInitializationForVarDecl(swift::VarDecl*, swift::Type) + 98
13 com.apple.LLDB.framework 0x0000000116ebbc74 swift::ASTVisitor<(anonymous namespace)::InitializationForPattern, void, void, void, std::__1::unique_ptr<swift::Lowering::Initialization, std::__1::default_delete<swift::Lowering::Initialization> >, void, void>::visit(swift::Pattern*) + 404
14 com.apple.LLDB.framework 0x0000000116ebbc57 swift::ASTVisitor<(anonymous namespace)::InitializationForPattern, void, void, void, std::__1::unique_ptr<swift::Lowering::Initialization, std::__1::default_delete<swift::Lowering::Initialization> >, void, void>::visit(swift::Pattern*) + 375
15 com.apple.LLDB.framework 0x0000000116ebba0d swift::Lowering::SILGenFunction::visitPatternBindingDecl(swift::PatternBindingDecl*) + 45
16 com.apple.LLDB.framework 0x0000000116f0617c swift::Lowering::SILGenFunction::visitBraceStmt(swift::BraceStmt*) + 284
17 com.apple.LLDB.framework 0x0000000116ecd1c0 swift::Lowering::SILGenFunction::emitFunction(swift::FuncDecl*) + 320
18 com.apple.LLDB.framework 0x0000000116ea3966 swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*) + 246
19 com.apple.LLDB.framework 0x0000000116ea3828 swift::Lowering::SILGenModule::visitFuncDecl(swift::FuncDecl*) + 168
20 com.apple.LLDB.framework 0x0000000116ea579b swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 427
21 com.apple.LLDB.framework 0x0000000116ea5c22 swift::SILModule::constructSIL(swift::Module*, swift::SILOptions&, swift::SourceFile*, llvm::Optional<unsigned int>, bool, bool) + 386
22 com.apple.LLDB.framework 0x0000000116ea5d42 swift::performSILGeneration(swift::SourceFile&, swift::SILOptions&, llvm::Optional<unsigned int>, bool) + 98
23 com.apple.LLDB.framework 0x00000001172aa617 lldb_private::SwiftExpressionParser::Parse(lldb_private::Stream&, unsigned int, unsigned int, unsigned int) + 10715
24 com.apple.LLDB.framework 0x000000011706b3e8 lldb_private::ClangUserExpression::Parse(lldb_private::Stream&, lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, unsigned int) + 1064
25 com.apple.LLDB.framework 0x000000011706cdb4 lldb_private::ClangUserExpression::Evaluate(lldb_private::ExecutionContext&, lldb_private::EvaluateExpressionOptions const&, char const*, char const*, lldb_private::SharingPtr<lldb_private::ValueObject>&, lldb_private::Error&, unsigned int, std::__1::shared_ptr<lldb_private::Module>*) + 628
26 com.apple.LLDB.framework 0x00000001171d1696 lldb_private::Target::EvaluateExpression(char const*, lldb_private::StackFrame*, lldb_private::SharingPtr<lldb_private::ValueObject>&, lldb_private::EvaluateExpressionOptions const&) + 376
27 com.apple.LLDB.framework 0x000000011716d75c lldb_private::SwiftLanguageRuntime::GetObjectDescription(lldb_private::Stream&, lldb_private::ValueObject&) + 668
28 com.apple.LLDB.framework 0x00000001170464e6 lldb_private::ValueObject::GetObjectDescription() + 370
29 com.apple.LLDB.framework 0x000000011548e228 lldb::SBValue::GetObjectDescription() + 76
30 com.apple.dt.dbg.DebuggerLLDB 0x00000001153f3c9e -[DBGLLDBDataValue _lldbValueObjectDescription] + 24
31 com.apple.dt.dbg.DebuggerLLDB 0x00000001153f3b7f -[DBGLLDBDataValue lldbDescription] + 29
32 com.apple.dt.dbg.DebuggerLLDB 0x00000001154023dc __87-[DBGLLDBSession printDescriptionOfDataValueToConsole:runAllThreads:completionHandler:]_block_invoke + 182
33 com.apple.dt.dbg.DebuggerLLDB 0x0000000115402e6d -[DBGLLDBSession handleNextActionWithState:withRunPending:] + 424
34 com.apple.dt.dbg.DebuggerLLDB 0x00000001153fdf44 DBGLLDBSessionThread(void*) + 980
35 libsystem_pthread.dylib 0x00007fff8ec12cb3 _pthread_body + 131
36 libsystem_pthread.dylib 0x00007fff8ec12c30 _pthread_start + 168
37 libsystem_pthread.dylib 0x00007fff8ec10419 thread_start + 13
Seems like we may be on the forefront of new technology here because I haven't found much help on this issue yet. I'm wondering if we have some sort of unusual configuration that is causing the compile time issues, or if there is a known reason why lldb might be crashing. Its the same on multiple different machines, with El Capitan, Yosemite, Xcode 6.3, Xcode 6.4. Any help is appreciated!
I've worked and I am actively working on projects that are probably even larger than yours (50+ libraries, hundreds of custom classes with thousands of LoC). It takes few seconds to compile and up to 2 minutes for release build (Late 2013 MBP), even for full Swift project.
I would highly recommend to look for other causes, as what this option tells you is that your problem is somewhere else since it affects app performance, not building speed. Maybe you have your .pch file full of stuff that does not belong there or something, it can cause this kind of slowing.
Other interesting thing is use of inference. I personally declare type for every single variable just because it is easier to read for others, but there is more to it. Since the inference can get complicated, it can cause compiler to take A LOT of time to figure out what your code actually does. Read this example article, though it was more like alpha-problem. BUT MAYBE, just maybe, you have something like this in your code as well. What would be worth doing is trying to remove all the swift code, compile libraries if that works well, then you know the problem is in your swift code and it will be probably connected to this.
Also, if you provide WHAT actually slows your build time (because you can see whole build process with timestamps, and there is high probability that one step will just take forever), it can help pinpoint the problem more accurately.
Hope it helps!
Edit: Another article on this interested topic
I managed to fix this in our project. (12 mins total compile time)
The key is to set the SWIFT_WHOLE_MODULE_OPTIMIZATION = YES as you say in the user defined settings
But you need to do one more change. You need to set the optimization level to None in debug otherwise you will not be able to debug your app.
I wrote a blog post about it here:
https://tech.zalando.com/blog/improving-swift-compilation-times-from-12-to-2-minutes/

VLCMobileKit iOS crash on screen lock on iPhone 4

I am facing a strange issue in MobileVLCKit for iOS.I am playing RTSP links in my app. I have set the flag to play audio and video in background to true in my app. So when the app goes in background the video playing in my VLC player keeps playing without any problem.
But on iPhone 4 (with iOS 7.0.4) when I lock the screen of my iPhone when the video is playing, the app crashes without showing any logs. Strange thing is that if I send the app in background by pressing home button then the app doesn't crash. The issue is only on iPhone 4 and not on iPhone 5.
Have somebody come across such issue before?
Bellow is device crash log:
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: 019323.846533 wlan.A[400] AppleBCMWLANNetManager::updateLinkQualityMetrics(): Report LQM to User Land 100, fAverageRSSI -69
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: ALS: AppleARMBacklight::setBacklightEnableGated 0 (set level to 0x1c8)
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: AppleMultitouchN1SPI: updating power statistics
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: ALS: AppleARMBacklight::handleMessageGated - framebufferState -> 0
May 27 03:18:41 My-iPhone-VI backboardd[28] <Notice>: Posting 'com.apple.iokit.hid.displayStatus' notifyState=0
May 27 03:18:41 My-iPhone-VI SpringBoard[34] <Warning>: [MPUNowPlayingController] Not registered for now playing notifications. Ignoring call to -unregisterForNotifications.
May 27 03:18:41 My-iPhone-VI backboardd[28] <Notice>: MultitouchHID: detection mode: 0->255
May 27 03:18:41 My-iPhone-VI MyApp[817] <Warning>: log: applicationWillResignActive
May 27 03:18:41 My-iPhone-VI MyApp[817] <Warning>: log: applicationDidEnterBackground
May 27 03:18:42 My-iPhone-VI profiled[818] <Notice>: (Note ) profiled: Service starting...
May 27 03:18:42 My-iPhone-VI ReportCrash[819] <Notice>: ReportCrash acting against PID 817
May 27 03:18:43 My-iPhone-VI ReportCrash[819] <Notice>: Formulating crash report for process MyApp[817]
May 27 03:18:43 My-iPhone-VI com.apple.launchd[1] (UIKitApplication:com.My.MyApp[0x19d8][817]) <Warning>: (UIKitApplication:com.My.MyApp[0x19d8]) Job appears to have crashed: Segmentation fault: 11
May 27 03:18:43 My-iPhone-VI backboardd[28] <Warning>: Application 'UIKitApplication:com.My.MyApp[0x19d8]' exited abnormally with signal 11: Segmentation fault: 11
May 27 03:18:43 My-iPhone-VI mediaserverd[46] <Warning>: Encountered an XPC error while communicating with backboardd: <error: 0x3cd9f744> { count = 1, contents =
"XPCErrorDescription" => <string: 0x3cd9f9dc> { length = 22, contents = "Connection interrupted" }
}
May 27 03:18:43 My-iPhone-VI ReportCrash[819] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/MyApp_2014-05-27-031842_My-iPhone-VI.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
May 27 03:18:53 My-iPhone-VI profiled[818] <Notice>: (Note ) profiled: Service stopping.
Below is the stack trace taken in method didEnterBackground:
Stack trace : (
0 MyApp 0x0010a191 -[MyAppAppDelegate applicationDidEnterBackground:] + 76
1 UIKit 0x2fc85543 <redacted> + 590
2 UIKit 0x2fc06ae1 <redacted> + 764
3 UIKit 0x2fc06721 <redacted> + 72
4 UIKit 0x2fc6bb3d <redacted> + 664
5 GraphicsServices 0x320a270d <redacted> + 608
6 GraphicsServices 0x320a22f7 <redacted> + 34
7 CoreFoundation 0x2d4599df <redacted> + 34
8 CoreFoundation 0x2d45997b <redacted> + 346
9 CoreFoundation 0x2d45814f <redacted> + 1398
10 CoreFoundation 0x2d3c2c27 CFRunLoopRunSpecific + 522
11 CoreFoundation 0x2d3c2a0b CFRunLoopRunInMode + 106
12 GraphicsServices 0x320a1283 GSEventRunModal + 138
13 UIKit 0x2fc66049 UIApplicationMain + 1136
14 MyApp 0x001078e9 main + 116
15 libdyld.dylib 0x37d26ab7 <redacted> + 2
)
You need to disable video decoding prior to entering the background state. Otherwise, MobileVLCKit will try to draw OpenGL contents in the background which will be prevented by the OS by terminating the app.
You can disable video decoding by setting the current video track on your media player instance to -1. Once your app is moved to the foreground again, switch it back to the currently decoded video track (so you should cache it if your stream includes more than one video track).
When disabling video decoding, audio decoding is not affected and will continue just fine. This approach also got the benefit of saving CPU load and battery.. ;)
This is how VLC for iOS works, too. :)
i think You need to disable video decoding prior to entering the background state,this will work for sure this is major thing Apple says that a fix for the home screen crashes is coming also you can read here more How to take a screenshot on iphone without using lock button

iOS Socket Connection Crashes

I have created socket connection mechanism in iOS. It is working quite well. But from time to time (around 1%) it is crashing. Here it is the crash log, do you have any idea why it is happening.
Thread 0 Crashed:
0 libobjc.A.dylib 0x3b01b5b0 _objc_msgSend + 16
1 CoreFoundation 0x332957cf _signalEventSync + 75
2 CoreFoundation 0x3329b623 _cfstream_solo_signalEventSync + 75
3 CoreFoundation 0x33295507 _CFStreamSignalEvent + 327
4 CFNetwork 0x32ffa6ff CoreWriteStreamCFStreamSupport::coreStreamWriteEvent(__CoreWriteStream*, unsigned long) + 99
5 CFNetwork 0x32ffa0b5 CoreWriteStreamClient::coreStreamEventsAvailable(unsigned long) + 37
6 CFNetwork 0x32ffb365 CoreStreamBase::_callClientNow() + 45
7 CFNetwork 0x32ffb0f9 CoreStreamBase::_streamSetEventAndScheduleDelivery(unsigned long, unsigned char) + 89
8 CFNetwork 0x32ffb4ff CoreStreamBase::_streamInterface_SignalEvent(unsigned long, CFStreamError const*) + 35
9 CFNetwork 0x32f69b57 SocketStream::socketCallback(__CFSocket*, unsigned long, __CFData const*, void const*) + 135
10 CFNetwork 0x32f69ab3 SocketStream::_SocketCallBack_stream(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 75
11 CoreFoundation 0x332cfd81 __CFSocketPerformV0 + 385
12 CoreFoundation 0x332cd683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
13 CoreFoundation 0x332ccf7f __CFRunLoopDoSources0 + 363
14 CoreFoundation 0x332cbcb7 __CFRunLoopRun + 647
15 CoreFoundation 0x3323eebd _CFRunLoopRunSpecific + 357
16 CoreFoundation 0x3323ed49 _CFRunLoopRunInMode + 105
17 GraphicsServices 0x36e172eb _GSEventRunModal + 75
18 UIKit 0x35154301 _UIApplicationMain + 1121
19 Okey101Plus 0x000e19ab main (main.m:16)
It looks like the socket class is trying to send a message to your delegate, and the delegate has become a zombie.
The NSStream class does not retain its delegate, unlike most other networking classes in iOS/OS X, so if you don't retain it somewhere, it will go away. Then, when the class tries to tell your class that the stream has data for reading or space for writing, you'll get a crash in objc_msgSend, like this one.
And if you do retain it, make sure you fully tear down the stream before you get rid of that retained delegate, and be careful about what thread you tear things down on, to ensure that there aren't callbacks already scheduled on the main run loop that will fire after you release the delegate.
Either that or you failed to implement a required delegate method. However, that doesn't fit with the "occurs rarely" bit. :-)
I'm not really really sure, but based on your report it looks like writing on socket fails -
CoreWriteStreamCFStreamSupport::coreStreamWriteEvent(__CoreWriteStream*, unsigned long) + 99
there is probably a way how you can avoid this error. CFNetworks Framework has a nice feature called CFNetDiagnostics reference. Please take a closer look at apple docs for it.
From Apple Docs:
In many network-based applications, network-based errors may occur that are unrelated to your application.(They probably mean here, for example: you can get reading error on socket, if the interface becomes unavailable, when network connection is lost) However, most users are probably unaware of why an application is failing. The CFNetDiagnostics API allows you a quick and easy way to help the user fix their network problems with little work on your end.
To diagnose the problem through the Network Diagnostic Assistant, call the CFNetDiagnosticDiagnoseProblemInteractively function and pass the network diagnostic reference. Listing 6-1 shows how to use CFNetDiagnostics with streams implemented on a run loop.
case kCFStreamEventErrorOccurred:
CFNetDiagnosticRef diagRef =
CFNetDiagnosticCreateWithStreams(NULL, stream, NULL);
(void)CFNetDiagnosticDiagnoseProblemInteractively(diagRef);
CFStreamError error = CFReadStreamGetError(stream);
reportError(error);
CFReadStreamClose(stream);
CFRelease(stream);
break;
You can read more here - Using Network Diagnostics, CFNetDiagnostics Reference

Resources