[IOS] Platform-views Deadlock caused by thread merging #94524
Comments
|
Hi @0xZOne, Thanks for filing the issue. Is this potential deadlock from the latest engine revision? Can you please share the output of Thanks |
maheshmnj
added
the
waiting for customer response
Yes, I think so. |
github-actions
bot
removed
the
waiting for customer response
|
@0xZOne, looking at your flutter doctor it looks like you are using an older version of flutter https://github.com/flutter/flutter/releases/tag/1.22.6, Please upgrade to latest Thanks |
maheshmnj
added
the
waiting for customer response
Yes, We found the deadlock in our actual ios app that uses flutter 1.22.6, as the log show. The deadlock only occurs in specific scenes occasionally and is hard to reproduce. Maybe the app will not upgrade to 2.5.x soon. But, According to the code logic, I believe that the deadlock here still exists in the latest version. In addition, there is also a potential deadlock risk in |PlatformViewAndroid|, although no cases have been found in an actual app not yet. |
github-actions
bot
removed
the
waiting for customer response
|
Thanks for the info, Leaving this issue open for further insights from the team. |
maheshmnj
added
a: production
maheshmnj
changed the title
cyanglaz
added this to Awaiting triage
in iOS Platform - platform view review
via automation
Complete crash logs have been added. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@flutter-symbolizer-bot #93791 (comment) engine#2f0af37152 ios release x86 |
|
crash from #94524 (comment) symbolized using symbols for |
|
The key symbol stack is already there. |
|
Are you sure the merger is happening before the red box? The only way I could see this deadlocking is if the threads get merged immediately after calling |
|
I suspect there might be a bug in the thread merger code - I'm not sure if I'm reading it right or not though. It seems like before merging threads, we should make sure to flush their task queues, otherwise we could run into these deadlocks in other places. @iskakaushik might know more about this, or @cyanglaz |
|
Chinmay tells me that we definitely don't flush the task queue(s) before merging. |
|
Duplicate of #94524? |
|
Sorry, I mean tto ask if it's a duplicate of #80491 |
dnfield
added
P1
@dnfield Sorry, perhaps I didn't make myself clear (I updated the issue description). I consider that thread merging and platform thread posting sync task to raster require a synchronization mechanism. |
|
@0xZOne - I agree there's a synchronization issue, but we should fix this in the general case for thread merging, rather than for one particular broken use case :) |
Yes, I totally agree with you. Here I have a question: Why must |
|
Unassigned myself as I don't have time to work on this at this moment. |
flutter-triage-bot
bot
added
multiteam-retriage-candidate
team-ios
|
This issue is marked P1 but has had no recent status updates. The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub. Please consider where this bug really falls in our current priorities, and label it or assign it accordingly. This allows people to have a clearer picture of what work is actually planned. Thanks! |
jmagman
added
P2
As shown below, If thread merging occurs before the code is executed in the green box, this results in a deadlock. As the task in the red box will never be executed, the current thread will always be blocked and will never be awoken.
For example:
1st scenario:
when the platform thread executes after A and before B, the raster thread preempts the CPU and obtains the right to execute, and starts thread merging (Assuming the raster task queue is empty now). When the platform thread gets the CPU again, the task continues to be put into the raster task queue, waiting for the platform thread to be processed later. But the platform thread will block at the C.
2nd scenario:
After the platform thread posts the sync task to the raster task queue (after B), the raster thread gets the CPU and starts thread merging immediately, and no chance to get the previous sync task to execute. The deadlock will also happen.
Related issue: #80491
Valuable stacktrace
Complete raw log
flutter doctor -v
The text was updated successfully, but these errors were encountered: