Closed acoutts closed 4 years ago
knaeckeKami
commented
4 years ago this is probably #65995
Do you use image_picker? If so, you can probably reproduce it by using a device with iOS 14, resetting the permissions of the app, selecting "select images" on the image picker permission prompt and opening the image picker a second time after that.
chinmaygarde
commented
4 years ago Can you confirm the use of the image picker? Chris has a fix for that in the issue linked by @knaeckeKami.
acoutts
commented
4 years ago In my case I do have the image picker lib in the app but the user was not using it during the crash. Is it an inherent issue with all image pickers in ios now?
chinmaygarde
commented
4 years ago Based on my conversation with @cyanglaz, this crash shows up for sure on iOS 14 on the second time the image picker is presented. We don't know the exact causes of the crash as it is private Apple frameworks. We were able to reproduce this in a non-Flutter app by just flushing transactions on a background thread (with no layouts). So I am not able to tell how else this may be reproducible (the stack trace is identical). But Chris does have a workaround for it in the other patch.
acoutts
commented
4 years ago Thanks! I'm wondering if the issue could be in the Intercom mobile SDK as the user was using that around the time of the crash, and they had used it to attach an image. Perhaps they're having the same issue in their SDK.
scutlight
commented
4 years ago Based on my conversation with @cyanglaz, this crash shows up for sure on iOS 14 on the second time the image picker is presented. We don't know the exact causes of the crash as it is private Apple frameworks. We were able to reproduce this in a non-Flutter app by just flushing transactions on a background thread (with no layouts). So I am not able to tell how else this may be reproducible (the stack trace is identical). But Chris does have a workaround for it in the other patch.
@chinmaygarde: We met the same crash with no image picker used there. Would you please give more details about the workaround? I'm confused why SubmitFrame on the raster thread would cause CALayer to layout.
Date/Time: 2020-09-26 14:57:02 +0000
OS Version: iPhone OS 14.0.1 (18A393)
Report Version: 104
Exception Type: SIGABRT
Exception Codes: #0 at 0x1ce46f95c
Crashed Thread: 51
Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.'
Last Exception Backtrace:
0 CoreFoundation 0x00000001a3af9114 __exceptionPreprocess + 216
1 libobjc.A.dylib 0x00000001b731fcb4 objc_exception_throw + 56
2 CoreAutoLayout 0x00000001b758f664 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints] + 0
3 CoreAutoLayout 0x00000001b758f33c -[NSISEngine _optimizeWithoutRebuilding] + 68
4 CoreAutoLayout 0x00000001b758ee9c -[NSISEngine optimize] + 104
5 CoreAutoLayout 0x00000001b758ab7c -[NSISEngine performPendingChangeNotifications] + 112
6 UIKitCore 0x00000001a682b4f4 -[UIView(Hierarchy) layoutSubviews] + 464
7 UIKitCore 0x00000001a683d954 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2464
8 QuartzCore 0x00000001a6d3d9e8 -[CALayer layoutSublayers] + 288
9 QuartzCore 0x00000001a6d43eb4 CA::Layer::layout_if_needed(CA::Transaction*) + 520
10 QuartzCore 0x00000001a6d4f1d0 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 140
11 QuartzCore 0x00000001a6c9b500 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 416
12 QuartzCore 0x00000001a6cc5698 CA::Transaction::commit() + 728
13 Flutter 0x000000010dff2da4 SubmitFrame (trace_event.h:330)
14 Flutter 0x000000010e5e8880 DrawToSurface (memory:2649)
15 Flutter 0x000000010e5e9528 DoDraw (rasterizer.cc:399)
16 Flutter 0x000000010e5ea600 operator() (rasterizer.cc:221)
17 Flutter 0x000000010e5e8cb0 Consume (memory:2649)
18 Flutter 0x000000010e5e89d0 Draw (rasterizer.cc:227)
19 Flutter 0x000000010e5fbc8c operator() (ref_ptr.h:103)
20 Flutter 0x000000010e003f18 FlushTasks (ref_ptr.h:116)
21 Flutter 0x000000010e00a2d4 OnTimerFire (message_loop_darwin.mm:76)
22 CoreFoundation 0x00000001a3a79a30 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
23 CoreFoundation 0x00000001a3a79634 __CFRunLoopDoTimer + 1004
24 CoreFoundation 0x00000001a3a78b14 __CFRunLoopDoTimers + 324
25 CoreFoundation 0x00000001a3a72eb0 __CFRunLoopRun + 1912
26 CoreFoundation 0x00000001a3a72200 CFRunLoopRunSpecific + 572
27 Flutter 0x000000010e00a3f8 Run (message_loop_darwin.mm:47)
28 Flutter 0x000000010e003e5c DoRun (message_loop_impl.cc:96)
29 Flutter 0x000000010e0081c4 __thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, (lambda at ../../flutter/fml/thread.cc:44:43)> > (thread:354)
30 libsystem_pthread.dylib 0x00000001e93dab70 _pthread_start + 288
31 libsystem_pthread.dylib 0x00000001e93df880 thread_start + 8This is everything we investigated to determine the cause of the image picker bug:
We initially suspected the Flutter engine was incorrectly causing layout of a UIKit view (or, a CALayer whose delegate was a UIKit view to be more precise). This may happen if someone calls setNeedsLayout on the layer or modified one of its properties that affects layout (bounds, position, anchor, etc..). We verified that this was not the case by setting thread specific breakpoints on these methods. Then we set a breakpoint on the [CALayer layoutSublayers] and dumped registers to find which layer was being laid out. This did not turn out to be a layer known to the Flutter engine and no Flutter managed view was part of the subviews of this view. For reference, in our case the view was a UIInputSetContainerView (this is not a view I am familiar with).
Then we tried to reproduce this issue without Flutter at all. In a vanilla iOS application, we showed the image picker while flushing transactions in a background thread. Something like
std::thread([](){
while (true)
{
[CATransaction begin];
// sleep
[CATransaction commit]
}
}).detach()We observed the same crash on the second instance of the launch of the image picker view with an identical backtrace. For whatever reason, the image picker view was being laid out in a transaction on a background thread even when that thread possibly couldn’t have caused layout of the layer (because it didn’t even have a handle to that layer).
We were sort of lost at this point and Chris then resorted to altering how the image picker was set up. This is when he discovered that changing the presentation style from the current UIModalPresentationCurrentContext to a popover (or one of a few other styles) was the trigger. We definitely don’t understand the issue and the “fix” is more of a workaround for the image picker. So, I don’t want to dismiss that this won’t happen on another view. My hope was that this was specific to the image picker but this may not be the case.
Also, this only happens on iOS 14 and only on a few devices.
This should be the full summary of what we did to investigate the issue.
If we cannot understand this issue (and honestly, we don’t at this point) but observe that it happens on other use cases, we may need to do something hacky like performing transaction less updates on the background thread. In fact, we may need to do that anyway since folks could be adding their own image pickers in an add-to-app scenario.
@scutlight: Can you tell a bit more about what was happening around the crash or is this from a crash reporting service without context? @cyanglaz: The more I think about this, while your workaround for the image picker issue is necessary, it is not sufficient. For cases where folks are adding such pickers to their apps on their own, or, other framework or SDKs adding such things , Flutter will still need to be resilient to failures. Can you investigate the transaction-less updates on the background thread as a proper fix please (well, its still a workaround since we don't know what's going to cause the erroneous layout).
chinmaygarde
commented
4 years ago Tentatively increasing the priority of this issue as I am not sure @cyanglaz is going to land his workaround for the image picker. I don't want us to consider this class of issues as fixed.
gaaclarke
commented
4 years ago @chinmaygarde Do you remember why we have a CATransaction? I removed the transaction and the crash goes away and there doesn't appear to be any adverse effect to the rendering. I'm guessing there is some case where we are editing the CoreAnimation layers I'm not hitting.
It might be flipping out because we are creating an empty transaction on that thread (which would be their bug). Maybe if we were a bit more tactical about only adding a transition when one is actually required might be a workaround?
chinmaygarde
commented
4 years ago Do you remember why we have a CATransaction?
The transaction should be necessary when the layer has its presentsWithTransaction property set to YES. We used to set this YES unconditionally at some point and I am not sure we do that today. I am not sure how you are not seeing adverse effects to rendering as the rendering should freeze when drawing very simple scenes. I remember having to add it for the camera preview example where all that was changing was the the texture provided by the plugin.
I removed the transaction and the crash goes away...
I suggested this to @cyanglaz and he said the crash was still happening. Chris, can you chime in on your observations? If this is indeed not happening if we don't explicitly push a transaction onto the transaction stack, then we should be able to work around this by setting presentsWithTransaction to NO on the background thread and not pushing any transactions.
I'm guessing there is some case where we are editing the CoreAnimation layers I'm not hitting.
This is what our first thought was too. But we coudln't find any instances of this happening when we set thread specific breakpoints on all the methods that could cause layout of a CA layer.
gaaclarke
commented
4 years ago I was testing with the image_picker example app. The button press animations were still working and the video I selected was playing even after a few presentations of the image picker. There isn't anything fancy being rendered in that app though either.
Here was my patch:
diff --git a/shell/platform/darwin/ios/ios_surface.mm b/shell/platform/darwin/ios/ios_surface.mm
index bcdb233ce..d4b420620 100644
--- a/shell/platform/darwin/ios/ios_surface.mm
+++ b/shell/platform/darwin/ios/ios_surface.mm
@@ -73,7 +73,7 @@ void IOSSurface::CancelFrame() {
platform_views_controller_->CancelFrame();
// Committing the current transaction as |BeginFrame| will create a nested
// CATransaction otherwise.
- [CATransaction commit];
+ // [CATransaction commit];
}
// |ExternalViewEmbedder|
@@ -84,7 +84,7 @@ void IOSSurface::BeginFrame(SkISize frame_size,
TRACE_EVENT0("flutter", "IOSSurface::BeginFrame");
FML_CHECK(platform_views_controller_ != nullptr);
platform_views_controller_->SetFrameSize(frame_size);
- [CATransaction begin];
+ // [CATransaction begin];
}
// |ExternalViewEmbedder|
@@ -104,7 +104,7 @@ PostPrerollResult IOSSurface::PostPrerollAction(
PostPrerollResult result = platform_views_controller_->PostPrerollAction(raster_thread_merger);
if (result == PostPrerollResult::kSkipAndRetryFrame) {
// Commit the current transaction if the frame is dropped.
- [CATransaction commit];
+ // [CATransaction commit];
}
return result;
}
@@ -131,7 +131,7 @@ void IOSSurface::SubmitFrame(GrDirectContext* context, std::unique_ptr<SurfaceFr
if (submitted) {
TRACE_EVENT0("flutter", "IOSSurface::DidSubmitFrame");
- [CATransaction commit];
+ // [CATransaction commit];
}
}
zanderso
commented
4 years ago Assigning to @cyanglaz based on our conversation yesterday, and marking for cherry-pick into 1.22. I believe this should not block the release, but please correct me if if I'm wrong.
cyanglaz
commented
4 years ago @gaaclarke The CATransaction is required for platform views (when threads are merged). We can probably patch it so that these methods only happens on the main thread.
However, I do still see the same crashes even after commenting out these methods.
gaaclarke
commented
4 years ago Removal of the transaction was working for me on an iPhone SE 2 device with iOS 14. On the simulator it crashes with a similar problem but a slightly different stack trace.
The crash in the simulator can be removed with the following patch, but it causes the screen to flash black for a frame the first time the image picker is presented:
--- a/shell/platform/darwin/ios/ios_surface_software.mm
+++ b/shell/platform/darwin/ios/ios_surface_software.mm
@@ -117,7 +117,11 @@ bool IOSSurfaceSoftware::PresentBackingStore(sk_sp<SkSurface> backing_store) {
return false;
}
- layer_.get().contents = reinterpret_cast<id>(static_cast<CGImageRef>(pixmap_image));
+ dispatch_sync(dispatch_get_main_queue(), ^{
+ [CATransaction begin];
+ layer_.get().contents = reinterpret_cast<id>(static_cast<CGImageRef>(pixmap_image));
+ [CATransaction commit];
+ });
return true;
}Since the layer in question is the one backing the UIView I wonder if we can ever safely edit it from a background thread because UIKit might be manipulating it at any point on the main thread. That's what the error seems to be suggesting, that editing the layer from a background thread is fine until the main thread touches it.
gaaclarke
commented
4 years ago I tried creating a sublayer in the FlutterView and passing that to the IOSurface, wondering if not using the surface that is directly backing the UIView might get around the problem. The crash 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.' still happened.
I think our options for the simulator crash are:
1) to run the raster thread on the platform thread for the simulator. This isn't ideal because it makes execution different than on device.
1) instead of setting the contents of the CALayer, using a custom CALayer that overrides - (void)drawInContext:(CGContextRef)ctx to draw the last skia image that was provided to it. That may still require dispatching a "setNeedsDisplay" onto the main thread which could cause latency in the rendering. There already is some latency between editing CALayers and seeing results.
1) Dispatching the setting of the contents field on the main thread like I mentioned in a previous comment. This will create latency too.
I suspect this problem arises because the way we are presenting that view controller happens to touch the layout engine on the main thread. UIKit could probably do this in other cases as well that we don't know about.
Safnaj
commented
4 years ago Based on my conversation with @cyanglaz, this crash shows up for sure on iOS 14 on the second time the image picker is presented. We don't know the exact causes of the crash as it is private Apple frameworks. We were able to reproduce this in a non-Flutter app by just flushing transactions on a background thread (with no layouts). So I am not able to tell how else this may be reproducible (the stack trace is identical). But Chris does have a workaround for it in the other patch.
Exactly, it causes when accessing image picker for the second time. Is there any solution guys ?? I have to deliver the app by this week.
cyanglaz
commented
4 years ago The issue has been fixed with https://github.com/flutter/engine/pull/21526 on iOS physical devices that uses metal.
I will follow up with an image_picker plugin workaround to fix the crash on the simulator.
If anyone can repro this crash without the image_picker plugin, please share a reduced steps to reproduce. It could help us on fixing the engine issue on simulators.
cyanglaz
commented
4 years ago Lowering the priority to P3 since this issue is fixed on devices, so it shouldn't block apps from shipping.
Safnaj
commented
4 years ago @cyanglaz It should be in P2 because, when we in the development process its really hard to always build the application in release mode and check it.
Safnaj
commented
4 years ago I just checked and its even causes in the releasemode for me
KhatibFX
commented
4 years ago Was this fix bundled with the current flutter 1.22 stable/beta branches?
cyanglaz
commented
4 years ago @Safnaj we fixed debugged mode too, but only on physical devices. i will land a workaround in the plugin to fix the simulator soon
@KhatibFX the fix is currently on master channel only
Safnaj
commented
4 years ago @cyanglaz is that fixed in v1.22 ??
cyanglaz
commented
4 years ago @Safnaj Not yet.
cpboyd
commented
4 years ago @cyanglaz While not this specific crash, probably related to the overall iOS 14 layout engine issues, have you seen any issues with widgets not responding after dismissing modals on the iOS simulator per https://github.com/flutter/flutter/issues/65995#issuecomment-703349645?
From testing, it seems that the button I'm using to launch the image_picker isn't actually processing the onTap (although the ripple triggers). Further, other widgets seemingly randomly don't work normally. Perhaps the non-UI threads are being held up for some reason?
If you haven't seen this, is there any way that I could possibly help gather debugging information?
cyanglaz
commented
4 years ago @cpboyd I haven't seen this. Is there a clear way to reproduce this issue(even it is not 100% reproducible)? If so, could you open a new issue with detailed repro steps?
cpboyd
commented
4 years ago @cyanglaz I'll try for a simplified repro
tamirrab
commented
4 years ago Intercom
Also got this with Intercom SDK then I open new chat
acoutts
commented
4 years ago Intercom
Also got this with Intercom SDK then I open new chat
Have you had it happen again? I haven’t seen it yet. They told me they may have fixed it but I’ve got no way to reproduce it to confirm.
tamirrab
commented
4 years ago Intercom
Also got this with Intercom SDK then I open a new chat
Have you had it happen again? I haven’t seen it yet. They told me they may have fixed it but I’ve got no way to reproduce it to confirm.
It's hard to restore the issue I delete the app and reinstall again and it's happened sometimes
I got the crash info on Crashlitycs
But I have 5 more users with iOS 14.0.1 with this issue
helenaford
commented
4 years ago I'm getting this error too. 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. After a fresh install works fine the first time, it's the second time I try to open the gallery.
var image;
try {
image = await ImagePicker().getImage(source: ImageSource.gallery);
if (image == null) return;
print(image);
} catch (e) {
print(e);
}
TakashiIshigakiApp
commented
4 years ago I'm getting this error too. I had a problem with iOS 14.1 and it works fine with iOS 13.5
Crash point
ImagePicker().getImage(source: ImageSource.gallery)
tamirrab
commented
4 years ago It's important to say: It's not only on Simulators!!
zanderso
commented
4 years ago Hey folks, @cyanglaz mentioned in https://github.com/flutter/flutter/issues/66647#issuecomment-703826831 that his work on this is not yet in 1.22. Please note that this issue is marked with the 'cp: 1.22' label, which means that it will be considered for a hotfix.
That being said, if you are on master channel, and you have @cyanglaz's relevant commits, and you are still seeing this problem, please don't hesitate to leave a comment here about that. Otherwise, please put a thumbs up on the issue to let us know this is important to you. Thanks!
cyanglaz
commented
4 years ago Closing this issue as it is fixed on the devices on master channel.
I opened another issue to track the crash on simulators: https://github.com/flutter/flutter/issues/67430. Please thumbs up https://github.com/flutter/flutter/issues/67430 if fixing the issue on simulator is important to you.
If anyone still sees this issue on iPhone devices on master channel, please feel free to leave a comment with details including the "flutter doctor -v" and the steps to reproduce. I will reopen the issue and investigate. Thanks!
paurakhsharma
commented
4 years ago @cyanglaz Thank you, this is fixed for me on the physical device as well as on the simulator. When can we expect it to land on stable release?
wszghj
commented
3 years ago 2020-11-07 10:37:14.738463+0800 Runner[56244:624227] flutter: Observatory listening on http://127.0.0.1:57464/IdmdtMDdpAQ=/ 2020-11-07 10:37:50.959673+0800 Runner[56244:624686] [core] "Error returned from daemon: Error Domain=com.apple.accounts Code=7 "(null)"" 2020-11-07 10:38:04.017853+0800 Runner[56244:624219] 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 CoreAutoLayout 0x00007fff582d4c53 _AssertAutoLayoutOnAllowedThreadsOnly + 190 1 CoreAutoLayout 0x00007fff582d49de -[NSISEngine _optimizeWithoutRebuilding] + 54 2 CoreAutoLayout 0x00007fff582d4511 -[NSISEngine optimize] + 92 3 CoreAutoLayout 0x00007fff582cf97c -[NSISEngine performPendingChangeNotifications] + 82 4 UIKitCore 0x00007fff24bb9fa6 -[UIView(Hierarchy) layoutSubviews] + 491 5 UIKitCore 0x00007fff24bcd686 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2874 6 QuartzCore 0x00007fff27a5ae67 -[CALayer layoutSublayers] + 258 7 QuartzCore 0x00007fff27a61319 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 575 8 QuartzCore 0x00007fff27a6d071 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 65 9 QuartzCore 0x00007fff279ad158 _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 496 10 QuartzCore 0x00007fff279e3ef3 _ZN2CA11Transaction6commitEv + 783 11 QuartzCore 0x00007fff279e50af _ZN2CA11Transaction17observer_callbackEP19CFRunLoopObservermPv + 79 12 CoreFoundation 0x00007fff203a76b3 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 23 13 CoreFoundation 0x00007fff203a1f3f CFRunLoopDoObservers + 547 14 CoreFoundation 0x00007fff203a24e2 CFRunLoopRun + 1113 15 CoreFoundation 0x00007fff203a1b9e CFRunLoopRunSpecific + 567 16 Flutter 0x00000001025b4781 _ZN3fml17MessageLoopDarwin3RunEv + 65 17 Flutter 0x00000001025af7fa _ZN3fml15MessageLoopImpl5DoRunEv + 22 18 Flutter 0x00000001025b3480 _ZNSt3114thread_proxyINS_5tupleIJNS_10unique_ptrINS_15thread_structENS_14default_deleteIS3_EEEEZN3fml6ThreadC1ERKNS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEE3$0EEEEEPvSJ + 170 19 libsystem_pthread.dylib 0x00007fff5dfa9109 _pthread_start + 148 20 libsystem_pthread.dylib 0x00007fff5dfa4b8b thread_start + 15 ) 2020-11-07 10:38:04.024061+0800 Runner[56244:624219] Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.' First throw call stack: ( 0 CoreFoundation 0x00007fff2043a126 exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007fff20177f78 objc_exception_throw + 48 2 CoreAutoLayout 0x00007fff582d4d41 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints] + 0 3 CoreAutoLayout 0x00007fff582d49de -[NSISEngine _optimizeWithoutRebuilding] + 54 4 CoreAutoLayout 0x00007fff582d4511 -[NSISEngine optimize] + 92 5 CoreAutoLayout 0x00007fff582cf97c -[NSISEngine performPendingChangeNotifications] + 82 6 UIKitCore 0x00007fff24bb9fa6 -[UIView(Hierarchy) layoutSubviews] + 491 7 UIKitCore 0x00007fff24bcd686 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2874 8 QuartzCore 0x00007fff27a5ae67 -[CALayer layoutSublayers] + 258 9 QuartzCore 0x00007fff27a61319 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 575 10 QuartzCore 0x00007fff27a6d071 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 65 11 QuartzCore 0x00007fff279ad158 _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 496 12 QuartzCore 0x00007fff279e3ef3 _ZN2CA11Transaction6commitEv + 783 13 QuartzCore 0x00007fff279e50af _ZN2CA11Transaction17observer_callbackEP19CFRunLoopObservermPv + 79 14 CoreFoundation 0x00007fff203a76b3 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 23 15 CoreFoundation 0x00007fff203a1f3f CFRunLoopDoObservers + 547 16 CoreFoundation 0x00007fff203a24e2 __CFRunLoopRun + 1113 17 CoreFoundation 0x00007fff203a1b9e CFRunLoopRunSpecific + 567 18 Flutter 0x00000001025b4781 _ZN3fml17MessageLoopDarwin3RunEv + 65 19 Flutter 0x00000001025af7fa _ZN3fml15MessageLoopImpl5DoRunEv + 22 20 Flutter 0x00000001025b3480 _ZNSt3114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEZN3fml6ThreadC1ERKNS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEE3$0EEEEEPvSJ + 170 21 libsystem_pthread.dylib 0x00007fff5dfa9109 _pthread_start + 148 22 libsystem_pthread.dylib 0x00007fff5dfa4b8b thread_start + 15 ) libc++abi.dylib: terminating with uncaught exception of type NSException *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.' terminating with uncaught exception of type NSException CoreSimulator 732.17 - Device: iPhone 12 (A7CF439B-FA3A-436C-BA6C-FECF210BD2E0) - Runtime: iOS 14.1 (18A8394) - DeviceType: iPhone 12
flutter1.22.3 image_picker: ^0.6.7+12 还没有解决吗？
CocoaZX
commented
3 years ago xuegangyang@XuedeMac-mini ~ % flutter doctor -v [✓] Flutter (Channel unknown, v1.12.13+hotfix.9, on Mac OS X 10.15.5 19F101, locale zh-Hans-CN) • Flutter version 1.12.13+hotfix.9 at /Users/xuegangyang/Desktop/flutter • Framework revision f139b11009 (7 months ago), 2020-03-30 13:57:30 -0700 • Engine revision af51afceb8 • Dart version 2.7.2
[!] Android toolchain - develop for Android devices (Android SDK version 29.0.3) • Android SDK at /Users/xuegangyang/Library/Android/sdk • Android NDK location not configured (optional; useful for native profiling support) • Platform android-29, build-tools 29.0.3 • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211) ✗ Android license status unknown. Try re-installing or updating your Android SDK Manager. See https://developer.android.com/studio/#downloads or visit https://flutter.dev/setup/#android-setup for detailed instructions.
[✓] Xcode - develop for iOS and macOS (Xcode 12.1) • Xcode at /Applications/Xcode.app/Contents/Developer • Xcode 12.1, Build version 12A7403 • CocoaPods version 1.9.1
[!] Android Studio (version 3.6) • Android Studio at /Applications/Android Studio.app/Contents ✗ Flutter plugin not installed; this adds Flutter specific functionality. ✗ Dart plugin not installed; this adds Dart specific functionality. • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)
[✓] VS Code (version 1.51.0) • VS Code at /Applications/Visual Studio Code.app/Contents • Flutter extension version 3.16.0
[✓] Connected device (1 available) • iPhone SE (2nd generation) • FABF0F7C-61F5-4017-8ADE-4E01653E4A25 • ios • com.apple.CoreSimulator.SimRuntime.iOS-14-0 (simulator)
When open the app & close the notification permission , it's crash maby 70%. but when I open notification permission ,will not crash.
error is NSInternalInconsistencyException Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread So strange I'm not use notification for any UI. And my application is full flutter
xiaoxiaowesley
commented
3 years ago @cyanglaz 's patch #21526 did't work for me.
But I found the root of the problem lies in shell/platform/darwin/ios/ios_render_targetgl.mm and after I comment the line 22 `[layer setPresentsWithTransaction:YES]`
https://github.com/flutter/engine/commit/5a78e0b630cb7e1a6d5107599e2579c18dab3048
When native view which contain animtion use CoreAnimation (e.g. Image picker and my case is LOTTIE ) is in front of Flutter View .Because Flutter is still running.So It will trigger native CALayer setNeedDisplay from raster thread when the layer in IOSRenderTargetGL has set to setPresentsWithTransaction to YES
Since we don't know the implement of CoreAnimation, but I suspect the funcion [CAEAGLayer nativeWindow] use the native to recursion the CALayers in current windows which is out of our expectation.
And the code is first merge in https://github.com/flutter/flutter/issues/24133 in order to use in platfrom view, but platformView has deprecated in 1.22 and I don't use it in my app so it ok to comment it.
https://flutter.dev/docs/development/platform-integration/platform-views
Here is apple documentation https://developer.apple.com/documentation/quartzcore/caeagllayer/1618676-presentswithtransaction?language=objc
cyanglaz
commented
3 years ago @xiaoxiaowesley This issue was only fixed on metal. I saw that in your case, it is running with GL, where the crash is still unfixed. What is the iOS model and version of your device?
xiaoxiaowesley
commented
3 years ago @cyanglaz ’s patch would't work for me. In my case
@xiaoxiaowesley This issue was only fixed on metal. I saw that in your case, it is running with GL, where the crash is still unfixed. What is the iOS model and version of your device?
iPhone 6 plus. iOS 14.3
github-actions[bot]
commented
3 years ago This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
I received this crash report in Crashlytics from a user in the wild. A user was using the app and upon returning to it, the app simply crashed without any error messages.
Unfortunately this means I don't have any way to reproduce the error, but I hope the stack traces caught can help identify the issue. I've included the flutter doctor output including the flutter framework version used to compile the app at the time the user had the issue.
Some information about their device:
Steps to Reproduce
n/a
Expected results: App should not crash without warning.
Actual results: The app suddenly exited (crashed) without any error to the user.
Additional thread dumps have been included in the summary section below.
Logs
``` com.apple.main-thread com.apple.main-thread 0 libsystem_kernel.dylib 0x1d620fdd0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x1d620f184 mach_msg + 76 2 CoreFoundation 0x1aa286cf8 __CFRunLoopServiceMachPort + 380 3 CoreFoundation 0x1aa280ea8 __CFRunLoopRun + 1216 4 CoreFoundation 0x1aa2804bc CFRunLoopRunSpecific + 600 5 GraphicsServices 0x1c0d05820 GSEventRunModal + 164 6 UIKitCore 0x1acc24734 -[UIApplication _run] + 1072 7 UIKitCore 0x1acc29e10 UIApplicationMain + 168 8 Runner 0x102363198 main + 7 (AppDelegate.swift:7) 9 libdyld.dylib 0x1a9f47e60 start + 4 com.apple.uikit.eventfetch-thread com.apple.uikit.eventfetch-thread 0 libsystem_kernel.dylib 0x1d620fdd0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x1d620f184 mach_msg + 76 2 CoreFoundation 0x1aa286cf8 __CFRunLoopServiceMachPort + 380 3 CoreFoundation 0x1aa280ea8 __CFRunLoopRun + 1216 4 CoreFoundation 0x1aa2804bc CFRunLoopRunSpecific + 600 5 Foundation 0x1ab4fde30 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 232 6 Foundation 0x1ab4fdd08 -[NSRunLoop(NSRunLoop) runUntilDate:] + 92 7 UIKitCore 0x1accd4e94 -[UIEventFetcher threadMain] + 516 8 Foundation 0x1ab6680f0 __NSThread__start__ + 864 9 libsystem_pthread.dylib 0x1f185aca8 _pthread_start + 320 10 libsystem_pthread.dylib 0x1f1863788 thread_start + 8 com.apple.NSURLConnectionLoader com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0x1d620fdd0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x1d620f184 mach_msg + 76 2 CoreFoundation 0x1aa286cf8 __CFRunLoopServiceMachPort + 380 3 CoreFoundation 0x1aa280ea8 __CFRunLoopRun + 1216 4 CoreFoundation 0x1aa2804bc CFRunLoopRunSpecific + 600 5 CFNetwork 0x1aab39050 _CFURLStorageSessionCopyCache + 63240 6 Foundation 0x1ab6680f0 __NSThread__start__ + 864 7 libsystem_pthread.dylib 0x1f185aca8 _pthread_start + 320 8 libsystem_pthread.dylib 0x1f1863788 thread_start + 8 io.flutter.1.ui io.flutter.1.ui 0 libsystem_kernel.dylib 0x1d620fdd0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x1d620f184 mach_msg + 76 2 CoreFoundation 0x1aa286cf8 __CFRunLoopServiceMachPort + 380 3 CoreFoundation 0x1aa280ea8 __CFRunLoopRun + 1216 4 CoreFoundation 0x1aa2804bc CFRunLoopRunSpecific + 600 5 Flutter 0x1032f12bc (Missing) 6 Flutter 0x1032f0c44 (Missing) 7 libsystem_pthread.dylib 0x1f185aca8 _pthread_start + 320 8 libsystem_pthread.dylib 0x1f1863788 thread_start + 8 io.flutter.1.io io.flutter.1.io 0 libsystem_kernel.dylib 0x1d620fdd0 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x1d620f184 mach_msg + 76 2 CoreFoundation 0x1aa286cf8 __CFRunLoopServiceMachPort + 380 3 CoreFoundation 0x1aa280ea8 __CFRunLoopRun + 1216 4 CoreFoundation 0x1aa2804bc CFRunLoopRunSpecific + 600 5 Flutter 0x1032f12bc (Missing) 6 Flutter 0x1032f0c44 (Missing) 7 libsystem_pthread.dylib 0x1f185aca8 _pthread_start + 320 8 libsystem_pthread.dylib 0x1f1863788 thread_start + 8 io.flutter.worker.1 io.flutter.worker.1 0 libsystem_kernel.dylib 0x1d623375c __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f185e550 _pthread_cond_wait + 1192 2 libc++.1.dylib 0x1be422c8c std::__1::condition_variable::wait(std::__1::unique_lock