View Full Version : Long hang on application termination
tuli
19th April 2013, 09:32
When i perform certain actions with my program, the program hangs for ~10-15 seconds on termination, at 100% cpu usage.
The main thread is destrying a custom object (as it should), but appears to have some issues within the destructor of an
typedef QMap<quint64, QSet< quint64> > trzf_cache;
object.
So the hang happens within Qt-map code.
Any ideas how any of my code could cause this?
edit:
completely rewrote posts with new details.
Santosh Reddy
19th April 2013, 12:16
When i perform certain actions with my program, the program hangs for ~10-15 seconds on termination, at 100% cpu usage.
Describe "certain actions".
So the hang happens within Qt-map code.
How can you tell that the delay is in QMap code?
Any ideas how any of my code could cause this?
That will be a wild guess :), unless we see code.
tuli
19th April 2013, 16:42
These "certain actions" is basically an entire sub-part of my program which makes extensive use of the datastruct defined above.
I can tell because all stack traces i gather end up there. :)
It appears that the data saved in the container(s) is about ~36 MB. An apparently it takes about 13 seconds to completely free it; and only then the program can be terminated.
Thing is, i dont remember having this kind of overhead with past revisions...let me take a look at some commit logs here... :S
There#s way too much code involved to show here - and i wouldnt even know what to show! :)
It basically adds, reads, deletes, modifies data stored in the container. Mostly read access, once it's set up, though.
Added after 1 35 minutes:
Interesting obersvation:
The data in trzf_cache is saved/loaded from/to disk using a QDataStream(). The filesize on disk vs. the memory consumption after loading it is 3x smaller, ie. 5MB on disk vs 15MB in memory.
This is not the case when i generate the data at runtime (which takes 5 minutes). If i do, the memory consumption is only 2x the filesize on disk (possibly even less, as i suspect memory leaks in the data generation).
And more importantly: with the data generated at runtime, there are no more delays when terminating the application!!
I#d suspect a buggy QDataStream implementation, but usually it#s me who makes the mistakes, not the Qt Devs.... :)
I'll try to debug some more...but if anyone has an idea, kindly let me know.
tuli
28th April 2013, 11:14
Update:
I refacrtored the code to use
typedef QMap<quint64, QVector< quint64> > trzf_cache;
instead of
typedef QMap<quint64, QSet< quint64> > trzf_cache;
and the problem appears to have gone.
No idea what difference that makes as with QDataStream vs. runtime generation...
saman_artorious
28th April 2013, 15:06
No idea what difference that makes as with QDataStream vs. runtime generation...
The difference: How would you describe a template providing Hash-Table based set with a template that provides dynamic array in terms of speed and efficiency ?
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.