Been encountering this error a lot in my OS X using swift:
"This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release."
I have a my NSWindow and I'm swapping in views to the contentView of the window. I get the error when I try and do a NSApp.beginSheet on the window, or when I add a subview to the window. Tried disabling autoresize stuff, and I don't have anything using auto layout. Any thoughts?
Sometimes it's fine and nothing happens, other times it totally breaks my UI and nothing loads
It needs to be placed inside a different thread that allows the UI to update as soon as execution of thread function completes:
Modern Swift:
DispatchQueue.main.async {
// Update UI
}
Older versions of Swift, pre Swift 3.
dispatch_async(dispatch_get_main_queue(){
// code here
})
Objective-C:
dispatch_async(dispatch_get_main_queue(), ^{
// code here
});
You get similar error message while debugging with print statements without using 'dispatch_async'
So when you get that error message, its time to use
Swift 4
DispatchQueue.main.async { //code }
Swift 3
DispatchQueue.main.async(){ //code }
Earlier Swift versions
dispatch_async(dispatch_get_main_queue()){ //code }
The "this application is modifying the autolayout engine from a background thread" error is logged in the console long after the actual problem occured, so debugging this can be hard without using a breakpoint.
I used #markussvensson's answer to detect my problem and found it using this Symbolic Breakpoint (Debug > Breakpoints > Create Symbolic Breakpoint):
Symbols: [UIView layoutIfNeeded] or [UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
Build and run the app on the emulator and replicate the steps that lead to the error message being thrown (the app will be slower than usual!). Xcode will then stop the app and mark the line of code (e.g. the call of a func) that's accessing the UI from a background thread.
When you try to update a text field value or adding a subview inside a background thread, you can get this problem. For that reason, you should put this kind of code in the main thread.
You need to wrap methods that call UI updates with dispatch_asynch to get the main queue. For example:
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.friendLabel.text = "You are following \(friendCount) accounts"
})
EDITED - SWIFT 3:
Now, we can do that following the next code:
// Move to a background thread to do some long running work
DispatchQueue.global(qos: .userInitiated).async {
// Do long running task here
// Bounce back to the main thread to update the UI
DispatchQueue.main.async {
self.friendLabel.text = "You are following \(friendCount) accounts"
}
}
For me, this error message originated from a banner from Admob SDK.
I was able to track the origin to "WebThread" by setting a conditional breakpoint.
Then I was able to get rid of the issue by encapsulating the Banner creation with:
dispatch_async(dispatch_get_main_queue(), ^{
_bannerForTableFooter = [[GADBannerView alloc] initWithAdSize:kGADAdSizeSmartBannerPortrait];
...
}
I don't know why this helped as I cannot see how this code was called from a non-main-thread.
Hope it can help anyone.
I had this problem since updating to the iOS 9 SDK when I was calling a block that did UI updates within an NSURLConnection async request completion handler. Putting the block call in a dispatch_async using dispatch_main_queue solved the issue.
It worked fine in iOS 8.
Had the same problem because I was using performSelectorInBackground.
Main problem with "This application is modifying the autolayout engine from a background thread" is that it seem to be logged a long time after the actual problem occurs, this can make it very hard to troubleshoot.
I managed to solve the issue by creating three symbolic breakpoints.
Debug > Breakpoints > Create Symbolic Breakpoint...
Breakpoint 1:
Symbol: -[UIView setNeedsLayout]
Condition: !(BOOL)[NSThread isMainThread]
Breakpoint 2:
Symbol: -[UIView layoutIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
Breakpoint 3:
Symbol: -[UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
With these breakpoints, you can easily get a break on the actual line where you incorrectly call UI methods on non-main thread.
You must not change the UI offside the main thread! UIKit is not thread safe, so that above problem and also some other weird problems will arise if you do that. The app can even crash.
So, to do the UIKit operations, you need to define block and let it be executed on the main queue: such as,
NSOperationQueue.mainQueue().addOperationWithBlock {
}
Obviously you are doing some UI update on back ground thread. Cant predict exactly where, without seeing your code.
These are some situations it might happen:-
you might be doing something on background thread and not using. Being in the same function this code is easier to spot.
DispatchQueue.main.async { // do UI update here }
calling a func doing web request call on background thread and its completion handler calling other func doing ui update.
to solve this try checking code where you have updated the UI after webrequest call.
// Do something on background thread
DispatchQueue.global(qos: .userInitiated).async {
// update UI on main thread
DispatchQueue.main.async {
// Updating whole table view
self.myTableview.reloadData()
}
}
I had this issue while reloading data in UITableView. Simply dispatching reload as follows fixed the issue for me.
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.tableView.reloadData()
})
I had the same problem. Turns out I was using UIAlerts that needed the main queue. But, they've been deprecated.
When I changed the UIAlerts to the UIAlertController, I no longer had the problem and did not have to use any dispatch_async code. The lesson - pay attention to warnings. They help even when you don't expect it.
You already have the correct code answer from #Mark but, just to share my findings:
The issue is that you are requesting a change in the view and assuming that it will happen instantly. In reality, the loading of a view depends on the available resources. If everything loads quickly enough and there are no delays then you don't notice anything. In scenarios, where there is any delay due to the process thread being busy etc, the application runs into a situation where it is supposed to display something even though its not ready yet. Hence, it is advisable to dispatch these requests in a asynchronous queues so, they get executed based on the load.
I had this issue when I was using TouchID if that helps anyone else, wrap your success logic which likely does something with the UI in the main queue.
It could be something as simple as setting a text field / label value or adding a subview inside a background thread, which may cause a field's layout to change. Make sure anything you do with the interface only happens in the main thread.
Check this link: https://forums.developer.apple.com/thread/7399
I had the same issue when trying to update error message in UILabel in the same ViewController (it takes a little while to update data when trying to do that with normal coding). I used DispatchQueue in Swift 3 Xcode 8 and it works.
If you want to hunt this error, use the main thread checker pause on issues checkbox.
Fixing it is easy most of the times, dispatching the problematic line in the main queue.
For me the issue was the following.
Make sure performSegueWithIdentifier: is performed on the main thread:
dispatch_async (dispatch_get_main_queue(), ^{
[self performSegueWithIdentifier:#"ViewController" sender:nil];
});
Swift 4,
Suppose, if you are calling some method using operation queue
operationQueue.addOperation({
self.searchFavourites()
})
And suppose function searchFavourites is like,
func searchFavourites() {
DispatchQueue.main.async {
//Your code
}
}
if you call, all code inside the method "searchFavourites" on the main thread, it will still give an error if you are updating some UI in it.
This application is modifying the autolayout engine from a background
thread after the engine was accessed from the main thread.
So use solution,
operationQueue.addOperation({
DispatchQueue.main.async {
self.searchFavourites()
}
})
For this kind of scenario.
Here check out this line from the logs
$S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
you can check that which function calling from the either background thread or where you are calling api method you need to call your function from the main thread like this.
DispatchQueue.main.async { func()}
func() is that function you want to call in the result of api call
success or else.
Logs Here
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
Stack:(
0 Foundation 0x00000001c570ce50 <redacted> + 96
1 Foundation 0x00000001c5501868 <redacted> + 32
2 Foundation 0x00000001c5544370 <redacted> + 540
3 Foundation 0x00000001c5543840 <redacted> + 396
4 Foundation 0x00000001c554358c <redacted> + 272
5 Foundation 0x00000001c5542e10 <redacted> + 264
6 UIKitCore 0x00000001f20d62e4 <redacted> + 488
7 UIKitCore 0x00000001f20d67b0 <redacted> + 36
8 UIKitCore 0x00000001f20d6eb0 <redacted> + 84
9 Foundation 0x00000001c571d124 <redacted> + 76
10 Foundation 0x00000001c54ff30c <redacted> + 108
11 Foundation 0x00000001c54fe304 <redacted> + 328
12 UIKitCore 0x00000001f151dc0c <redacted> + 156
13 UIKitCore 0x00000001f151e0c0 <redacted> + 152
14 UIKitCore 0x00000001f1514834 <redacted> + 868
15 UIKitCore 0x00000001f1518760 <redacted> + 104
16 UIKitCore 0x00000001f1543370 <redacted> + 1772
17 UIKitCore 0x00000001f1546598 <redacted> + 120
18 UIKitCore 0x00000001f14fc850 <redacted> + 1452
19 UIKitCore 0x00000001f168f318 <redacted> + 196
20 UIKitCore 0x00000001f168d330 <redacted> + 144
21 AppName 0x0000000100b8ed00 $S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
22 AppName 0x0000000100b8d9f4 $S12CcfU0_y10Foundation4DataVSg_So13NSURLResponseCSgs5Error_pSgtcfU_ + 2384
23 App NAme 0x0000000100a98f3c $S10Foundation4DataVSgSo13NSURLResponseCSgs5Error_pSgIegggg_So6NSDataCSgAGSo7NSErrorCSgIeyByyy_TR + 316
24 CFNetwork 0x00000001c513aa00 <redacted> + 32
25 CFNetwork 0x00000001c514f1a0 <redacted> + 176
26 Foundation 0x00000001c55ed8bc <redacted> + 16
27 Foundation 0x00000001c54f5ab8 <redacted> + 72
28 Foundation 0x00000001c54f4f8c <redacted> + 740
29 Foundation 0x00000001c55ef790 <redacted> + 272
30 libdispatch.dylib 0x000000010286f824 _dispatch_call_block_and_release + 24
31 libdispatch.dylib 0x0000000102870dc8 _dispatch_client_callout + 16
32 libdispatch.dylib 0x00000001028741c4 _dispatch_continuation_pop + 528
33 libdispatch.dylib 0x0000000102873604 _dispatch_async_redirect_invoke + 632
34 libdispatch.dylib 0x00000001028821dc _dispatch_root_queue_drain + 376
35 libdispatch.dylib 0x0000000102882bc8 _dispatch_worker_thread2 + 156
36 libsystem_pthread.dylib 0x00000001c477917c _pthread_wqthread + 472
37 libsystem_pthread.dylib 0x00000001c477bcec start_wqthread + 4
)
I also encountered this problem, seeing a ton of these messages and stack traces being printed in the output, when I resized the window to a smaller size than its initial value. Spending a long time figuring out the problem, I thought I'd share the rather simple solution. I had once enabled Can Draw Concurrently on an NSTextView through IB. That tells AppKit that it can call the view's draw(_:) method from another thread. After disabling it, I no longer got any error messages. I didn't experience any problems before updating to macOS 10.14 Beta, but at the same time, I also started modifying the code to perform work with the text view.
I received a crash log that I cannot explain. I have searched around and it appears that the SIGSEGV has something to do with memory. But in my case there is nothing of my own code except for the main.m in the stacktrace. Also it doesn't seem to symbolicate any of the system libraries.
The crash so far only happened on one iPhone. On other phones I haven't been able to reproduce it. Right now I'm completely stuck and don't know where to continue so if anyone has seen something like this before it would be good to hear their problem and resolution.
The crash log:
Incident Identifier: TODO
CrashReporter Key: TODO
Hardware Model: iPhone4,1
OS Version: iPhone OS 6.1.3 (10B329)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x41fd5903
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x3b0b9564 0x3b0b6000 + 13668
1 libobjc.A.dylib 0x3b0bb1d7 0x3b0b6000 + 20951
2 CoreFoundation 0x33396605 0x332d4000 + 796165
3 CoreFoundation 0x3339635d 0x332d4000 + 795485
4 libobjc.A.dylib 0x3b0bea65 0x3b0b6000 + 35429
5 libc++abi.dylib 0x3ab0b07b 0x3ab0a000 + 4219
6 libc++abi.dylib 0x3ab0b114 0x3ab0a000 + 4372
7 libc++abi.dylib 0x3ab0c599 0x3ab0a000 + 9625
8 libobjc.A.dylib 0x3b0be9d1 0x3b0b6000 + 35281
9 CoreFoundation 0x332dcf21 0x332d4000 + 36641
10 CoreFoundation 0x332dcd49 0x332d4000 + 36169
11 GraphicsServices 0x36eb52eb 0x36eb0000 + 21227
12 UIKit 0x351f2301 0x3519b000 + 357121
13 Stylbar 0x0007109f main (main.m:21)
Edit 3th of May:
The crash log is sent by a user. I haven't been able to reproduce the issue myself unfortunately, which is why it's so difficult for me to figure out what went wrong with just this crash log.
It appeared to have happened about 15 times in a row for the same user when opening a certain view controller. The view controller does several calls to a server to load a post, comments and images and profile pictures. All the code that's executed when this view controller is opened is probably over 2000 lines of code (excluding the RestKit and SBWebImage libraries that are used within this code). Posting that code here wouldn't help anyone I'm afraid.
The most simple and useful way to spend your time hunting for the cause of the crash is to look at your code and focus on places where UIKit has a delegate that points back into your code. For example, I found that the most common place this sort of thing would show up was in UITableView. The reason these problems are so hard to track down is that they might only happen in a low memory situation or in some uncommon UI condition that is very hard to reproduce. It is better to just do a code review and make sure that delegate that are set to point to your classes are set back to nil in your own object destructors. If you have many developers, it is often better to work on some higher level abstractions like a generic table and cell class that is used throughout the project than to have every developer coding up a UITableView and making mistakes like forgetting to nil out the delegate that are very difficult to find.
SIGSEGV is a problem the occurs when your application tries to access an address of memory that doesn't exists or some address where is already reserved to another program. I have the same issue with an application right now but I have to review my code to figure it out better. One clue for this kind of problem could be something equivalent to this (found in wikipedia):
#include <stdlib.h>
int main(void)
{
char p = NULL; / p is a pointer to char that initializes poiting to "nowhere"*/
* p = 'x'; /* Tries to save the char 'x' in 'no address'*/
return 0;
}
I hope this can help someone.
I've been trying to research this error for a while, but to no avail. Every time it looks like TGAccessoryManager should be sending my application data, an argument exception occurs:
2013-04-30 11:46:01.905 mindyieldapp[14537:907] Exception: *** -[NSDictionary initWithDictionary:copyItems:]: dictionary argument is not an NSDictionary
2013-04-30 11:46:01.918 mindyieldapp[14537:907] Stack trace: (
0 CoreFoundation 0x33d7f2bb <redacted> + 186
1 libobjc.A.dylib 0x3ba2497f objc_exception_throw + 30
2 CoreFoundation 0x33d0bff5 <redacted> + 212
3 mindyieldapp 0x000c1539 -[TGAccessoryManager fireDataReceived:] + 336
I'm certain my code is wired up correctly, as I've stripped it down significantly, and the accessoryDidConnect/accessoryDidDisconnect selectors are being called. I'm targeting iOS 6.1, with the latest version of the Neurosky SDK (I just re-downloaded to be sure). Any assistance is appreciated.
The error is quite clear, copyItems is not an instance of NSDicitonary. Put a breakpoint on
the line with [NSDictionary initWithDictionary:copyItems:] and see of what type is copyItems instance of.
This issue is specific to RestKit, but I believe the underlying issue is related to registering to notifications. I could really use some help figuring this one out...I seem to be having the same issue appearing multiple times:
An NSInvalidArguementException coming from
serviceDidBecomeUnavailableNotification within RKClient. The action
is calling from __NSMallocBlock__, __NSCFString, __NSCFArray, NSURL,
and UICFFont... obviously the delegate is not being set correctly.
It is ONLY in my requests using RKObjectMapping to map the response to
my model classes. I've noticed the objectLoader has
isResponseMappable and checks [self.response isServiceUnavailable] -
which then posts a RKServiceDidBecomeUnavailableNotification. This
seems to be where my issue is coming from. The only place I see
isResponseMappable being called is within didFinishLoad:(RKResponse*)response.
Here's an example stack trace, I thought this could be very beneficial:
Error Message:
NSInvalidArgumentException: -[__NSMallocBlock__
serviceDidBecomeUnavailableNotification:]: unrecognized selector sent
to instance 0xee168b0
CoreFoundation:2:in `0x37d4dacb -[NSObject doesNotRecognizeSelector:]
+ 174'
CoreFoundation:3:in `0x37d4c945 ___forwarding___ + 300'
CoreFoundation:4:in `0x37ca7680 _CF_forwarding_prep_0 + 48'
Foundation:5:in `0x31c6f50f __57-[NSNotificationCenter
addObserver:selector:name:object:]_block_invoke_0 + 18'
CoreFoundation:6:in `0x37d16577 ___CFXNotificationPost_block_invoke_0
+ 70'
CoreFoundation:7:in `0x37ca20cf _CFXNotificationPost + 1406'
Foundation:8:in `0x31be33fb -[NSNotificationCenter
postNotificationName:object:userInfo:] + 66'
Foundation:9:in `0x31be4c2b -[NSNotificationCenter
postNotificationName:object:] + 30'
MyApp:10:in `0x000d2157 -[RKObjectLoader isResponseMappable] + 114'
MyApp:11:in `0x000d2b83 -[RKObjectLoader didFinishLoad:] + 418'
MyApp:12:in `0x000cb151 -[RKResponse connectionDidFinishLoading:] +
36'
Foundation:13:in `0x31ca6c39 __65-[NSURLConnectionInternal
_withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 16'
Foundation:14:in `0x31bfe6e9 -[NSURLConnectionInternalConnection
invokeForDelegate:] + 28'
If anyone has any helpful tips, ideas, or suggestions on how to debug this, it would be greatly appreciated! I've been dealing with this for two weeks and am only seeing it in deployed apps (cannot replicate the issue) so any insight is better than none! Cheers!
Check whether you have add all the frame works recommended for RestKit, in your project
1. **CFNetwork.framework**
1. **CoreData.framework**
1. **MobileCoreServices.framework**
1. **SystemConfiguration.framework**
1. **libxml2.dylib**
Just incase any others fall onto this solution, the approach I took was:
Completely remove RestKit from my existing project. I then downloaded the master branch of RestKit, reintegrated into my project (there were some deprecated methods, less necessary frameworks, and refactored classes, but all in all pretty simple). I will be releasing this version with the new RestKit within the next week or so, and HOPE to not see this issue arising again.:)
If I do have this issue, I will come back and modify my answer with a reason for why it's still happening.
I've been looking at crash logs generated by an iphone app today:
Thread 0 Crashed:
0 libobjc.A.dylib 0x3002d7da 0x3002b000 + 10202
1 UIKit 0x31ec4abc 0x31e4d000 + 490172
2 UIKit 0x31ebd214 0x31e4d000 + 459284
3 UIKit 0x31ebcfac 0x31e4d000 + 458668
Can anyone tell me what the hex addresses mean? (memory addresses, sure..)
I know how to symbolicate to produce:
0 libobjc.A.dylib 0x000027da objc_msgSend + 18
1 UIKit 0x00077abc -[UINavigationController _startDeferredTransitionIfNeeded] + 176
2 UIKit 0x00070214 -[UINavigationController pushViewController:transition:forceImmediate:] + 600
3 UIKit 0x0006ffac -[UINavigationController pushViewController:animated:] + 28
and debug the crash from there, but I'm curious; if you take
0x3002d7da 0x3002b000 + 10202
then: 0x3002d7da = 0x3002b000 + (decimal) 10202
What does this signify exactly?
I should add I'm not looking for info on how to symbolicate, thx!
EDIT: what is also strange to me is that if you compare pre and post symbolicated versions, then for code I wrote:
9 memleaktest 0x00002ffe 0x1000 + 8190
becomes
9 memleaktest 0x00002ffe -[memleaktestViewController buttonOne] (memleaktestViewController.m:24)
makes sense, but for framework code:
8 CoreFoundation 0x307fe52c 0x307f8000 + 25900
becomes
8 CoreFoundation 0x0000652c -[NSObject(NSObject) release] + 24
the address and offset has changed? Why would this be?
if you take
0x3002d7da 0x3002b000 + 10202
What does this signify exactly?
In this case, the "+" doesn't signify addition so much. What this line is telling you is:
The routine/library in question starts at address 0x3002b000
Your line-of-code in the stack trace happened 10202 bytes into it.
The sum of those two numbers = 0x3002d7da
(Put another way, as you did, 0x3002d7da = 0x3002b000 + 10202.)
The important thing about which you might care is the start address of the method being called.
But, really, you can ignore all of that, since it's not nearly as useful as the symbolicated version, which gives you source-file name & line-number.
Extending Olie's response on the "symbolicated version" of the app: The debugging information is stripped from the distribution version of the app to make it smaller and also to protect the developer's intellectual property (so you can't see class and method names).
In order to decrypt the log, you need to have the debugging symbols file associated with the specific build that created the crash log.
This file (.dSYM extension) will be present in the build folder where the binary of the iPhone app is also located. Please note that you need the .dSYM file for the specific compilation that was used to compile the app on the phone - the dSYM file is timestamped, so if you recompile the app, the dSYM file will change even if you don't change a line of code.
Once you have this file on your computer, drag the crash file into xcode (or view logs from attached devices in the Organiser), which will give you a stack trace of the methods called and the specific lines of code called which led to the crash.