summaryrefslogtreecommitdiffstats
path: root/examples/applicationmanager/application-features
diff options
context:
space:
mode:
authorRobert Griebl <robert.griebl@qt.io>2022-10-11 18:25:05 +0200
committerQt Cherry-pick Bot <cherrypick_bot@qt-project.org>2022-10-12 11:09:50 +0000
commit19692eed8e7411298b2e2ac0afdf94bb9e1d0336 (patch)
tree5e90d47cb5232f7ce9a155b6cbcb10b138c1fea3 /examples/applicationmanager/application-features
parent041552bf7423885f9a9cc295aeb85d6222b71441 (diff)
Fix a potential crash when trying to start applications6.3
If you were calling startApplication() and the runtime failed to execute the app's binary in a container, it would call deleteLater() on the failed runtime object. The problem was that if you immediately called startApplication() once more in the same event loop iteration, the Application object still had the to-be-deleted runtime attached, which in turn prevents the allocation of a new container, so the AM tried to start the application again, but this time with "container" set to nullptr. The actual fix is to NOT call deleteLater, but directly delete the runtime object. In addition, when startApplication() is called for an application, we have to make sure that the application's runtime object can not be in the state NotRunning: the AM could still end up in this state, if a Container plugin is either not reporting shutdown correctly, or if the container's "ready" state is delayed. Change-Id: Ied1baec8c90d4e0a980c296cbc7cd87b12629524 Reviewed-by: Dominik Holland <dominik.holland@qt.io> (cherry picked from commit 5ae261864728678df3dd72f156efc6688dcf695d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Diffstat (limited to 'examples/applicationmanager/application-features')
0 files changed, 0 insertions, 0 deletions