diff options
author | Murray Read <ext-murray.2.read@nokia.com> | 2012-02-08 14:16:27 (GMT) |
---|---|---|
committer | Qt by Nokia <qt-info@nokia.com> | 2012-02-09 15:23:50 (GMT) |
commit | a13b2a248e5091ddf21e3c5ac08c9ddf0b940b5b (patch) | |
tree | 8f1e58987a7c2178af754d871d40782296fad496 /examples/mainwindows | |
parent | a784bdcabe895ab927cbc28118d427c6e932b9fc (diff) | |
download | Qt-a13b2a248e5091ddf21e3c5ac08c9ddf0b940b5b.zip Qt-a13b2a248e5091ddf21e3c5ac08c9ddf0b940b5b.tar.gz Qt-a13b2a248e5091ddf21e3c5ac08c9ddf0b940b5b.tar.bz2 |
Avoiding early deleteLater in Symbian with better loopLevel tracking
There have been a number of app crashes where deleteLater has been
triggering too early, causing an object to be deleted before it has
been finished with. This was happening when deleteLater was issued
then Symbian's active scheduler loop was nested. Qt keeps track of
loop nesting level to implement deleteLater correctly, but it was
only tracking the event loop in processEvents and QEventLoop correctly.
The wakeup and timer active objects were assuming they were always
run from processEvents and its round robin active scheduler and were
adjusting the loop level to account for this. However if they happened
to run in another event loop, eg the active scheduler, the loop level
adjustment meant that it looked like the event loop was re-running at
the same level, which allowed deleteLater to act.
The fix is to mark active objects as being run from the RR scheduler,
then the wakeup and timer active objects can be tested to see which
type of scheduler they are actually running in. With this knowledge,
the correct loop level adjustment can be made, and deleteLater runs
at the correct time.
Task-number: ou1cimx1#947013
Change-Id: Id05cd63ad10e100ea807cc276844aaa36c614351
Reviewed-by: Gareth Stockwell <ext-gareth.stockwell@nokia.com>
Reviewed-by: Shane Kearns <ext-shane.2.kearns@nokia.com>
Diffstat (limited to 'examples/mainwindows')
0 files changed, 0 insertions, 0 deletions