summaryrefslogtreecommitdiffstats
path: root/examples/mainwindows
diff options
context:
space:
mode:
authorMurray Read <ext-murray.2.read@nokia.com>2012-02-08 14:16:27 (GMT)
committerQt by Nokia <qt-info@nokia.com>2012-02-09 15:23:50 (GMT)
commita13b2a248e5091ddf21e3c5ac08c9ddf0b940b5b (patch)
tree8f1e58987a7c2178af754d871d40782296fad496 /examples/mainwindows
parenta784bdcabe895ab927cbc28118d427c6e932b9fc (diff)
downloadQt-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