Crash apparently caused by auto-layout UI changes on background thread

I've been getting occasional crash reports that look similar to this:


Fatal Exception: NSInternalInconsistencyException
Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.

Fatal Exception: NSInternalInconsistencyException
0  CoreFoundation                 0x19dcd0a48 __exceptionPreprocess
1  libobjc.A.dylib                0x19d9f7fa4 objc_exception_throw
2  Foundation                     0x19e1a6f08 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints]
3  Foundation                     0x19dfa803c -[NSISEngine withBehaviors:performModifications:]
4  UIKitCore                      0x1a20ff8e8 -[UIView(UIConstraintBasedLayout) _resetLayoutEngineHostConstraints]
5  UIKitCore                      0x1a21d9314 -[UIView(CALayerDelegate) layoutSublayersOfLayer:]
6  QuartzCore                     0x1a473c7dc -[CALayer layoutSublayers]
7  QuartzCore                     0x1a4742958 CA::Layer::layout_if_needed(CA::Transaction*)
8  QuartzCore                     0x1a474d578 CA::Layer::layout_and_display_if_needed(CA::Transaction*)
9  QuartzCore                     0x1a4695f1c CA::Context::commit_transaction(CA::Transaction*, double)
10 QuartzCore                     0x1a46bfc08 CA::Transaction::commit()
11 QuartzCore                     0x1a46c0b8c CA::Transaction::release_thread(void*)
12 libsystem_pthread.dylib        0x19d9eefb0 _pthread_tsd_cleanup
13 libsystem_pthread.dylib        0x19d9ebde8 _pthread_exit
14 libsystem_pthread.dylib        0x19d9ece7c _pthread_wqthread_legacy_worker_wrap
15 libsystem_pthread.dylib        0x19d9ecc18 _pthread_wqthread
16 libsystem_pthread.dylib        0x19d9ef760 start_wqthread

This is not being invoked by my code (at least directly). I've been running the app in the debugger with the Main Thread Checker enabled and have yet to catch whatever is causing this.


I've found multiple reports from others who have been experiencing similar issues, most commonly on iOS 13. (My app only supports 13 and later.) I have yet to see any solid explanation. @Eskimo - is it possible that iOS is invoking something that results in a UI state change which is called from a background thread?


Thanks,


-S

Post not yet marked as solved Up vote post of ssokol Down vote post of ssokol
7.3k views

Replies

Is it autolayout or layout for a collectionView ?


You don't tell anything about yoyur code, where the crash occurs…


So, pretty hard to imagine what could be going on, knowing that the first suspect should be your code, not iOS…

My code is, definitely, the first suspect in this. But I've been running the app in the debugger with the main thread checker engaged for days and while I've caught other issues I've never managed to trap this particular issue.


As I said, it doesn't appear to be taking place in my code, so I can't tell what view is the source. What you see in the trace is what I get. I can't find any point in my code where I'm manipulating constraints that might be called from a background thread or queue. As you can see, this error takes place on a thread that's executing system code - there's no reference in there to my app ("FlightBox_PFD").


Any suggestions?

Do you use any third party framework ?


Tha's the second usual suspect…

I'm using several libraries (Pods) in source form - which I would expect to show up in the debugger if they were misbehaving - and one binary framework. The framework is a custom Metal-based mapping engine and while it does create layers they are always children of the host UIView and shouldn't have any impact on the layout. I won't say it's impossible, but I've been using the same framework for 2+ years without any problems.


If this is my code or something from a 3rd party library, why doesn't the call stack show it? I would at least expect to see some kind of "enqueued from" indicator that I could use to track down the source of the offending call.

  • The same crash from my App with A Custom Metal Render Engine, So I can definitely located this problem which caused by the metal thread background rendering. It seems like METAL Render invokes in some time the app isn't become to the ACTIVE state , and the METAL Rendering caused the AutoLayout at the background thread. I had make some protected (by delay the Metal Rendering when app become active ) on the latest version of my app , and saw the the effects which reduces 76% bugs of this crash. but haven't solved perfectly , seems it still has some rarely scenario invoke background rendering . so looking forward to Apple's official solution

Add a Comment

I've been using the same framework for 2+ years without any problems.


Yes, but maybe one was not totally compliant but got working in previous OS. And no more with iOS 13 (I already noticed that some API behavior have changed here and there).


Did you search on the forums for those libraries for any problem with iOS 13 ?

We have this crash in Crashes organizer in Xcode in our App Store app.

Its a top crash.

Did you ever found out what the cause of the crash was?

I have several similar crash reports from users , but have not been able to reproduce it myself.
Do you think it is suspicious that the UI layout is initiated from a pthread_exit ? Could that be a lead for finding the answer?
Bump!

We are experience the same problems on different iOS (14.2, 14.1, 14.3, 14.4, 13.7, 13.6)

Never managed to catch this exception in debug. The only thing we've noticed that app was in a background for a while before that, so this could happens after the app goes foreground. We still not sure about that.
same problem
Same problem here, after app was in background for a while, switched to foreground and crash, sometimes.
I am having exactly the same issue with my app, the app crashes either on background or when it's in background and I reopen it.
The crash logs says its something related to the auto layout

CoreAutoLayout: _NSBitSetResize + 236

I could not find anything related to this issue. How could we ask one of the Apple Specialists to help us?

It's very annoying since the app crashes almost 10 times per day.

Same problem. Does anyone has workaround?

Same here. Looking for additional info on how to approach this or any info that could help us catching this.

Fatal Exception: NSInternalInconsistencyException 0 CoreFoundation 0x9cb4 __exceptionPreprocess 1 libobjc.A.dylib 0x183d0 objc_exception_throw 2 CoreAutoLayout 0xde68 NSISLinExpReplaceVarWithVarPlusDelta 3 CoreAutoLayout 0x4994 -[NSISEngine _optimizeWithoutRebuilding] 4 CoreAutoLayout 0x48c4 -[NSISEngine optimize] 5 CoreAutoLayout 0x4650 -[NSISEngine performPendingChangeNotifications] 6 UIKitCore 0x6420 -[UIView(Hierarchy) layoutSubviews] 7 UIKitCore 0x4be0 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] 8 QuartzCore 0xa074 CA::Layer::layout_if_needed(CA::Transaction*) 9 QuartzCore 0x1d5f0 CA::Layer::layout_and_display_if_needed(CA::Transaction*) 10 QuartzCore 0x2ea1c CA::Context::commit_transaction(CA::Transaction*, double, double*) 11 QuartzCore 0x5dff4 CA::Transaction::commit() 12 QuartzCore 0xa879c CA::Transaction::release_thread(void*) 13 libsystem_pthread.dylib 0x1b9c _pthread_tsd_cleanup 14 libsystem_pthread.dylib 0x4560 _pthread_exit 15 libsystem_pthread.dylib 0x10cc pthread_main_np 16 libsystem_pthread.dylib 0xe64 _pthread_wqthread 17 libsystem_pthread.dylib 0xb7c start_wqthread

I also encountered the same problem, the Main Thread Checker that opened Xcode has not been able to track the specific location, but there is this crash feedback online every day. At present, I check that all devices with iOS 16.0 system or above appear, and we need the official to help us solve this intractable problem

我也遇到同样的问题,开启Xcode的Main Thread Checker始终没有追踪到具体位置,但是线上每天都会有这个奔溃反馈,我目前查看都是iOS 16.0系统以上的设备出现,需要官方来帮助我们解决一下这个棘手的问题

We urgently need expert Apple engineers to help us