PDA

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 ?