Memory leaks with QDomElement::tagName()

[saracaeus]

Hello,

this is the scenario:
- VStudio2005, using Qt4.7.2, built for VS2005 (dumpbin -imports on the Qt libs refering to VS80 libs)
- I build another dll which links QtXml4.dll

THIS method is creating memory leaks:



int CTestClass::blubber( int iBlubber )
{
QDomElement aRoot;
aRoot.tagName();
return 0;
}


and THE SAME method with commented tagName() is NOT creating memory leaks:


int ARGOSXml_DomParser::blubber( int iBlubber )
{
QDomElement aRoot;
// aRoot.tagName();
return 0;
}

NOTE: I do NOT call this method! just linking!

I am really helpless... perhaps anyone got an idea!

If you need more information, please ask!

Any help is appreciated!
saracaeus

[Lykurg]

How do you measure that it is a memory leak? I can't see it.

[wysota]

This is how this method is implemented:


QString QDomElement::tagName() const
{
if (!impl)
return QString();
return impl->nodeName();
}
I don't see where it could possibly leak memory.

[saracaeus]

well, thats exactly why I am helpless... I have no clue... the memory leaks coming from VS2005, this is the output:



Detected memory leaks!
Dumping objects ->
{220} normal block at 0x012F4550, 24 bytes long.
Data: < > 00 CD CD CD 00 00 00 00 00 00 00 00 00 00 00 00
{219} normal block at 0x012F44F0, 32 bytes long.
Data: < > 01 00 00 00 03 00 00 00 00 00 00 00 01 00 00 00
{218} normal block at 0x012F44B0, 4 bytes long.
Data: < D/ > F0 44 2F 01
{217} normal block at 0x012F4458, 24 bytes long.
Data: < > 00 CD CD CD 00 00 00 00 00 00 00 00 00 00 00 00
{216} normal block at 0x012F4410, 12 bytes long.
Data: <XD/ ;g ;g> 58 44 2F 01 C8 DD 3B 67 C8 DD 3B 67
{215} normal block at 0x012F43B8, 24 bytes long.
Data: < > 00 CD CD CD 00 00 00 00 00 00 00 00 00 00 00 00
{214} normal block at 0x012F4370, 12 bytes long.
Data: < C/ ;g ;g> B8 43 2F 01 C8 DD 3B 67 C8 DD 3B 67
{213} normal block at 0x012F4318, 24 bytes long.
Data: < > 00 CD CD CD 00 00 00 00 00 00 00 00 00 00 00 00
{212} normal block at 0x012F42B8, 36 bytes long.
Data: < C/ pC/ D/ > 18 43 2F 01 70 43 2F 01 10 44 2F 01 00 00 00 00
{211} normal block at 0x012F4278, 4 bytes long.
Data: < B/ > B8 42 2F 01
{210} normal block at 0x012F4238, 4 bytes long.
Data: < Y.g> A8 59 2E 67
Object dump complete.
The thread 'Win32 Thread' (0x814) has exited with code 0 (0x0).


And as I noted: the method is NOT even called!

And once i comment this line, the memory leaks are gone!

:(

[wysota]

When is that "leak" reported? If the method is not called, it can't possibly create a memory leak. If you have a leak then it is elsewhere.

[saracaeus]

The "leaks" are reported after the application is closed.

It cant be elsewhere => if I comment this line, the leaks are gone!!!

And of course a memory leak can happen w/o calling the method. Think about static objects etc. I dont have the Qt code, so I have no clue what is allocated and what not!

I am not a dll-specialist on the other hand and it can be a runtime library problem. normally I like to use static links. So perhaps anyone got an idea about that.

The same I have discovered with the QFile-constructor. Once i use it in a method, these memory leaks are there.

Added after 9 minutes:

I remember a similar problem:

if a class has got a std::vector member and doesnt define a virtual destructor, then the vector is not free'd when the object is destroyed, because the vector's destructor isnt called, which is causing memory leaks!

It might be somethin like that!

As I said: I dont have the Qt-code and I am not familiar with it. So I hope there is somebody out there who got an idea :)

[wysota]

It cant be elsewhere => if I comment this line, the leaks are gone!!!
No, they are not gone. They are not being reported.


And of course a memory leak can happen w/o calling the method. Think about static objects etc.
With static objects a constructor is being called that can cause a memory leak.


I dont have the Qt code, so I have no clue what is allocated and what not!
I posted implementation of that method. There is no allocation there apart copying a string (which doesn't do any heap allocation).


if a class has got a std::vector member and doesnt define a virtual destructor, then the vector is not free'd when the object is destroyed, because the vector's destructor isnt called, which is causing memory leaks!
Well, this is not the case here. You are not constructing anything because you're not even calling any code.

Again, there is no leak there.

Does your reporting tool report a leak for this code?


#include <QDomElement>

void func() {
QDomElement e;
e.tagName();
}

int main() { return 0; }

[saracaeus]

Following your suggestion I made another test: I created a new MFC application (I forgot to state this at the beginning, that I am using MFC). A blank MFC application from scratch doesnt produce memory leaks. Then I added this method again:



void CTestProject2005Doc::Blubber( void )
{
QDomElement e;
e.tagName();
}


First case: using MFC in a static library => NO MEMORY LEAKS
Second case: using MFC in a dynamic library => MEMORY LEAKS

So it must be a runtime library problem, but as I stated before, I am not a dll-specialist and thus dont have a clue why a dynamically linked MFC library together with a Qt-dll creates these memory leaks and a statically linked MFC library doesnt.

So wherever the problem is, I hope that somebody has an idea to solve it :)

Thank you in advance, whoever helps me!

[wysota]

There is no problem... You are experiencing a false positive.

[d_stranz]

I have read that the reason for these apparent memory leaks is that the DLLs used in MFC are loaded at startup and unloaded at shutdown in a different order, so these "leaks" are the result of MFC objects that have not been deleted by the time the library is unloaded.

I see this all the time. All I have to do is to declare an instance of the custom file browser we use in our apps (which is implemented in an MFC-based DLL), without actually invoking it, and I get thousands of lines of leaks reported on shutdown. You also see it when using MFC-based ActiveX controls.

It is a real pain in the butt, because it makes finding real memory leaks so much harder when you have to wade through thousands of lines of nonsense to spot the one real report.