Long hang on application termination

[tuli]

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;

typedef QMap<quint64, QSet< quint64> > trzf_cache;

To copy to clipboard, switch view to plain text mode 

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]

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]

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]

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]

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 ?