Fix a deadlock in remote COPC handling (3D views) #56388
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This gets often triggered from 3D views when the hierachy gets fetched, because a QEventLoop gets started in the main thread while waiting for network request to be finished. The event loop was running with hierarchy mutex locked, which was causing deadlocks when other events ended up trying to access the hierarchy. This fix unlocks the mutex while the hierarchy network request is ongoing (the same approach as remote EPT implementation uses, which seems to work fine). Looking at the copc/ept hierarchy handling, it is not great - both formats are conceptually the same, yet the hierarchy implementations are different, and there are also non-trivial differences between local/remote datasets. All of this could get some code cleanups (also unifying local/remote access), but at this time let's just try to fix the worst bit, and hope something else does not break...
nyalldawson
approved these changes
Feb 17, 2024
wonder-sk
added a commit
to wonder-sk/QGIS
that referenced
this pull request
Feb 20, 2024
Follow up of qgis#56388 It was possible to trigger a deadlock when using a local COPC file by zooming in/out while there was 2D rendering happening - this caused a situation where point cloud index was trying to recursively lock a mutex that the same thread has already locked. fetchNodeHierarchy() for local COPC files now unlocks the mutex before calling fetchHierarchyPage() just like what happens with remote COPC files. While fixing that, I have removed now duplicate code between the local and remote COPC support. The logic for dealing with hierarchy mutex should be clearer now as well - we do not call other functions of the index with mutex locked.
nyalldawson
pushed a commit
that referenced
this pull request
Feb 21, 2024
Follow up of #56388 It was possible to trigger a deadlock when using a local COPC file by zooming in/out while there was 2D rendering happening - this caused a situation where point cloud index was trying to recursively lock a mutex that the same thread has already locked. fetchNodeHierarchy() for local COPC files now unlocks the mutex before calling fetchHierarchyPage() just like what happens with remote COPC files. While fixing that, I have removed now duplicate code between the local and remote COPC support. The logic for dealing with hierarchy mutex should be clearer now as well - we do not call other functions of the index with mutex locked.
wonder-sk
added a commit
to wonder-sk/QGIS
that referenced
this pull request
Feb 21, 2024
Follow up of qgis#56388 It was possible to trigger a deadlock when using a local COPC file by zooming in/out while there was 2D rendering happening - this caused a situation where point cloud index was trying to recursively lock a mutex that the same thread has already locked. fetchNodeHierarchy() for local COPC files now unlocks the mutex before calling fetchHierarchyPage() just like what happens with remote COPC files. While fixing that, I have removed now duplicate code between the local and remote COPC support. The logic for dealing with hierarchy mutex should be clearer now as well - we do not call other functions of the index with mutex locked. (cherry picked from commit 13446ee)
nyalldawson
pushed a commit
that referenced
this pull request
Feb 21, 2024
Follow up of #56388 It was possible to trigger a deadlock when using a local COPC file by zooming in/out while there was 2D rendering happening - this caused a situation where point cloud index was trying to recursively lock a mutex that the same thread has already locked. fetchNodeHierarchy() for local COPC files now unlocks the mutex before calling fetchHierarchyPage() just like what happens with remote COPC files. While fixing that, I have removed now duplicate code between the local and remote COPC support. The logic for dealing with hierarchy mutex should be clearer now as well - we do not call other functions of the index with mutex locked. (cherry picked from commit 13446ee)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This gets often triggered from 3D views when the hierachy gets fetched, because a QEventLoop gets started in the main thread while waiting for network request to be finished. The event loop was running with hierarchy mutex locked, which was causing deadlocks when other events ended up trying to access the hierarchy. This fix unlocks the mutex while the hierarchy network request is ongoing (the same approach as remote EPT implementation uses, which seems to work fine).
Looking at the copc/ept hierarchy handling, it is not great - both formats are conceptually the same, yet the hierarchy implementations are different, and there are also non-trivial differences between local/remote datasets. All of this could get some code cleanups (also unifying local/remote access), but at this time let's just try to fix the worst bit, and hope something else does not break...