Qt-interest Archive, July 2007
Detect memory leak and corruption on Qt
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Hello, everyone.
I have a touble of memory(resource) leak and memory corruption in my
large program on Qt.
Current environment is WindowXP 64bit Edition, and Intel Compiler. Qt4.3
VisualStudio can't detect following bugs
char *Buff=new char[100];
memset(Buff,0,101);
or
char *Buff=new char[100];
Buff=new char[100]; //former allocation stays without deletion
Does Qt do anything for "new" "delete"?
I tried some commercial debugging tools. But it didn't work good on
Window 64bit environment. Does anyone know good tool or nice method?
===================================
Masatoshi Sasai
--
[ signature omitted ]
Message 2 in thread
Qt only takes care of its own object hierarchy (i.e. whenever you set a
parent for a QObject derived class, Qt takes care about it). In your
example you do a normal allocation that has nothing to do with Qt, as
such Qt does not take ownership of your allocation and will free the memory.
ms441125 schrieb:
> Hello, everyone.
>
> I have a touble of memory(resource) leak and memory corruption in my
> large program on Qt.
> Current environment is WindowXP 64bit Edition, and Intel Compiler. Qt4.3
> VisualStudio can't detect following bugs
> char *Buff=new char[100];
> memset(Buff,0,101);
> or
> char *Buff=new char[100];
> Buff=new char[100]; //former allocation stays without deletion
>
> Does Qt do anything for "new" "delete"?
>
> I tried some commercial debugging tools. But it didn't work good on
> Window 64bit environment. Does anyone know good tool or nice method?
>
>
>
> ===================================
> Masatoshi Sasai
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 3 in thread
I tried both, boost unit test and Boundschecker and get 7 memory
leaks reported with a single line test program like
main(int argc, char* argv[])
{
QCoreApplication app(argc, argv);
}
Some allocations for threading seem to get left behind when
QCoreApplication is constructed and destructed:
>> qthread_win.cpp, line 73, 77
>> qmutex.cpp, line 157
>> qthread.cpp, line 139
>> qlocale.cpp line 1239, 1247
A pretty annoying issue, since I cannot run automated memory
leak detection unit tests because of that.
That is with the release version of Qt 4.3.0, static build, win32,
both release and debug.
Please, please fix it!
DavidF
Thomas Dähling wrote:
> Qt only takes care of its own object hierarchy (i.e. whenever you set a
> parent for a QObject derived class, Qt takes care about it). In your
> example you do a normal allocation that has nothing to do with Qt, as
> such Qt does not take ownership of your allocation and will free the
> memory.
>
> ms441125 schrieb:
>> Hello, everyone.
>>
>> I have a touble of memory(resource) leak and memory corruption in my
>> large program on Qt. Current environment is WindowXP 64bit Edition,
>> and Intel Compiler. Qt4.3
>> VisualStudio can't detect following bugs
>> char *Buff=new char[100];
>> memset(Buff,0,101);
>> or char *Buff=new char[100];
>> Buff=new char[100]; //former allocation stays without deletion
>>
>> Does Qt do anything for "new" "delete"?
>>
>> I tried some commercial debugging tools. But it didn't work good on
>> Window 64bit environment. Does anyone know good tool or nice method?
>>
>>
>> ===================================
>> Masatoshi Sasai
>>
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 4 in thread
On 07.07.07 20:01:03, David Forstenlechner wrote:
> I tried both, boost unit test and Boundschecker and get 7 memory
> leaks reported with a single line test program like
>
> main(int argc, char* argv[])
> {
> QCoreApplication app(argc, argv);
> }
>
> Some allocations for threading seem to get left behind when
> QCoreApplication is constructed and destructed:
>
> >> qthread_win.cpp, line 73, 77
> >> qmutex.cpp, line 157
> >> qthread.cpp, line 139
> >> qlocale.cpp line 1239, 1247
>
> A pretty annoying issue, since I cannot run automated memory
> leak detection unit tests because of that.
>
> That is with the release version of Qt 4.3.0, static build, win32,
> both release and debug.
>
> Please, please fix it!
Have you investigated the issues? I mean did you check the code? There
may be false positive's reported by your leak checkers, Qt uses a couple
of global statics that are only cleaned up during the application
shutdown (or unloading of a plugin).
Andreas
--
[ signature omitted ]
Message 5 in thread
All of those look more like global statics that are only deallocated at app shutdown.
A very typical false positive for memory leak tests... I would setup a filter to turn them off.
Scott
> -----Original Message-----
> From: David Forstenlechner [mailto:dforsten@xxxxxxxxxx]
> Sent: Saturday, July 07, 2007 11:01 AM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Re: Detect memory leak and corruption on Qt
>
> I tried both, boost unit test and Boundschecker and get 7 memory
> leaks reported with a single line test program like
>
> main(int argc, char* argv[])
> {
> QCoreApplication app(argc, argv);
> }
>
> Some allocations for threading seem to get left behind when
> QCoreApplication is constructed and destructed:
>
> >> qthread_win.cpp, line 73, 77
> >> qmutex.cpp, line 157
> >> qthread.cpp, line 139
> >> qlocale.cpp line 1239, 1247
>
> A pretty annoying issue, since I cannot run automated memory
> leak detection unit tests because of that.
>
> That is with the release version of Qt 4.3.0, static build, win32,
> both release and debug.
>
> Please, please fix it!
>
> DavidF
>
> Thomas Dähling wrote:
> > Qt only takes care of its own object hierarchy (i.e. whenever you set a
> > parent for a QObject derived class, Qt takes care about it). In your
> > example you do a normal allocation that has nothing to do with Qt, as
> > such Qt does not take ownership of your allocation and will free the
> > memory.
> >
> > ms441125 schrieb:
> >> Hello, everyone.
> >>
> >> I have a touble of memory(resource) leak and memory corruption in my
> >> large program on Qt. Current environment is WindowXP 64bit Edition,
> >> and Intel Compiler. Qt4.3
> >> VisualStudio can't detect following bugs
> >> char *Buff=new char[100];
> >> memset(Buff,0,101);
> >> or char *Buff=new char[100];
> >> Buff=new char[100]; //former allocation stays without deletion
> >>
> >> Does Qt do anything for "new" "delete"?
> >>
> >> I tried some commercial debugging tools. But it didn't work good on
> >> Window 64bit environment. Does anyone know good tool or nice method?
> >>
> >>
> >> ===================================
> >> Masatoshi Sasai
> >>
> >> --
> >> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> >> "unsubscribe" in the subject or the body.
> >> List archive and information: http://lists.trolltech.com/qt-interest/
> >>
> >>
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > "unsubscribe" in the subject or the body.
> > List archive and information: http://lists.trolltech.com/qt-interest/
> >
> >
> >
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 6 in thread
A simple program like the one in
/example/tutorial/t1
reports 81 memory leaks,
would be pretty hard to filter all those out manually.
Pretty much defeats the purpose of automated memory leak detection.
There needs to be a way to clean up these dependencies,
they are all explicitly allocated using the "new" operator,
no static instances.
I use a few singletons in my code too, but I do provide functions
to clean up before exit, explicitly to be able to run memory leak tests,
would be nice if Qt would provide something like that too.
Which memory leak detection software are you using,
and can you reproduce my results?
- DavidF
Scott Aron Bloom wrote:
> All of those look more like global statics that are only deallocated at app shutdown.
>
> A very typical false positive for memory leak tests... I would setup a filter to turn them off.
>
> Scott
>
>> -----Original Message-----
>> From: David Forstenlechner [mailto:dforsten@xxxxxxxxxx]
>> Sent: Saturday, July 07, 2007 11:01 AM
>> To: qt-interest@xxxxxxxxxxxxx
>> Subject: Re: Detect memory leak and corruption on Qt
>>
>> I tried both, boost unit test and Boundschecker and get 7 memory
>> leaks reported with a single line test program like
>>
>> main(int argc, char* argv[])
>> {
>> QCoreApplication app(argc, argv);
>> }
>>
>> Some allocations for threading seem to get left behind when
>> QCoreApplication is constructed and destructed:
>>
>>>> qthread_win.cpp, line 73, 77
>>>> qmutex.cpp, line 157
>>>> qthread.cpp, line 139
>>>> qlocale.cpp line 1239, 1247
>> A pretty annoying issue, since I cannot run automated memory
>> leak detection unit tests because of that.
>>
>> That is with the release version of Qt 4.3.0, static build, win32,
>> both release and debug.
>>
>> Please, please fix it!
>>
>> DavidF
>>
>> Thomas Dähling wrote:
>>> Qt only takes care of its own object hierarchy (i.e. whenever you set a
>>> parent for a QObject derived class, Qt takes care about it). In your
>>> example you do a normal allocation that has nothing to do with Qt, as
>>> such Qt does not take ownership of your allocation and will free the
>>> memory.
>>>
>>> ms441125 schrieb:
>>>> Hello, everyone.
>>>>
>>>> I have a touble of memory(resource) leak and memory corruption in my
>>>> large program on Qt. Current environment is WindowXP 64bit Edition,
>>>> and Intel Compiler. Qt4.3
>>>> VisualStudio can't detect following bugs
>>>> char *Buff=new char[100];
>>>> memset(Buff,0,101);
>>>> or char *Buff=new char[100];
>>>> Buff=new char[100]; //former allocation stays without deletion
>>>>
>>>> Does Qt do anything for "new" "delete"?
>>>>
>>>> I tried some commercial debugging tools. But it didn't work good on
>>>> Window 64bit environment. Does anyone know good tool or nice method?
>>>>
>>>>
>>>> ===================================
>>>> Masatoshi Sasai
>>>>
>>>> --
>>>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>>>> "unsubscribe" in the subject or the body.
>>>> List archive and information: http://lists.trolltech.com/qt-interest/
>>>>
>>>>
>>> --
>>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>>> "unsubscribe" in the subject or the body.
>>> List archive and information: http://lists.trolltech.com/qt-interest/
>>>
>>>
>>>
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 7 in thread
David Forstenlechner wrote:
> A simple program like the one in
> /example/tutorial/t1
> reports 81 memory leaks,
> would be pretty hard to filter all those out manually.
> Pretty much defeats the purpose of automated memory leak detection.
>
> There needs to be a way to clean up these dependencies,
> they are all explicitly allocated using the "new" operator,
> no static instances.
>
> I use a few singletons in my code too, but I do provide functions
> to clean up before exit, explicitly to be able to run memory leak tests,
> would be nice if Qt would provide something like that too.
>
> Which memory leak detection software are you using,
> and can you reproduce my results?
>
>
Memory Validator (www.softwareverify.com) reports no leaks on that example
if I tell it not to hook the Qt dll's (as I don't want to see any false
errors from
inside Qt).
- Keith
--
[ signature omitted ]
Message 8 in thread
Unfortunately when linking statically excluding the dlls is
not possible :-(
I am not sure if these leaks can be labeled "false positives"
though.
Explicitly allocated memory should be cleaned up before shutdown.
- DavidF
Keith Sabine wrote:
> David Forstenlechner wrote:
>> A simple program like the one in
>> /example/tutorial/t1
>> reports 81 memory leaks,
>> would be pretty hard to filter all those out manually.
>> Pretty much defeats the purpose of automated memory leak detection.
>>
>> There needs to be a way to clean up these dependencies,
>> they are all explicitly allocated using the "new" operator,
>> no static instances.
>>
>> I use a few singletons in my code too, but I do provide functions
>> to clean up before exit, explicitly to be able to run memory leak tests,
>> would be nice if Qt would provide something like that too.
>>
>> Which memory leak detection software are you using,
>> and can you reproduce my results?
>>
>>
> Memory Validator (www.softwareverify.com) reports no leaks on that example
> if I tell it not to hook the Qt dll's (as I don't want to see any false
> errors from
> inside Qt).
>
> - Keith
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 9 in thread
David Forstenlechner wrote:
> Unfortunately when linking statically excluding the dlls is
> not possible :-(
>
Well there are other ways of excluding the Qt code from checking. And if
you really want
to do leak checking, why not dynamically link anyhow - you can still
statically link your
production code?
- Keith
--
[ signature omitted ]
Message 10 in thread
On 07.07.07 21:34:49, David Forstenlechner wrote:
> Unfortunately when linking statically excluding the dlls is
> not possible :-(
>
> I am not sure if these leaks can be labeled "false positives"
> though.
Yes they can.
> Explicitly allocated memory should be cleaned up before shutdown.
Unless I'm mistaken they are cleaned up properly, see Q_GLOBAL_STATIC
and the Qt source for how that works. The thing is that they are cleaned
up "pretty late" and thus often are reported as memory leaks.
Andreas
--
[ signature omitted ]
Message 11 in thread
I see,
the globals using Q_GLOBAL_STATIC have a mechanism to be cleaned up
before shutdown,
is there a way to trigger the deletion of the globals explicitly?
That would make memory leak detection much more convenient.
- DavidF
Andreas Pakulat wrote:
> On 07.07.07 21:34:49, David Forstenlechner wrote:
>> Unfortunately when linking statically excluding the dlls is
>> not possible :-(
>>
>> I am not sure if these leaks can be labeled "false positives"
>> though.
>
> Yes they can.
>
>> Explicitly allocated memory should be cleaned up before shutdown.
>
> Unless I'm mistaken they are cleaned up properly, see Q_GLOBAL_STATIC
> and the Qt source for how that works. The thing is that they are cleaned
> up "pretty late" and thus often are reported as memory leaks.
>
> Andreas
>
--
[ signature omitted ]
Message 12 in thread
On a closer look static variables and static variables defined using
Q_GLOBAL_STATIC do not seem to be a problem, the leaks detected
are unrelated to statics and seem to be real leaks.
Boundschecker is very well capable not to report static
variables or memory allocated by static variables as memory leaks,
if the static variables clean up the memory they allocated properly.
Definitely something for Trolltech to look at.
- DavidF
David Forstenlechner wrote:
> I see,
> the globals using Q_GLOBAL_STATIC have a mechanism to be cleaned up
> before shutdown,
> is there a way to trigger the deletion of the globals explicitly?
> That would make memory leak detection much more convenient.
>
> - DavidF
>
> Andreas Pakulat wrote:
>> On 07.07.07 21:34:49, David Forstenlechner wrote:
>>> Unfortunately when linking statically excluding the dlls is
>>> not possible :-(
>>>
>>> I am not sure if these leaks can be labeled "false positives"
>>> though.
>> Yes they can.
>>
>>> Explicitly allocated memory should be cleaned up before shutdown.
>> Unless I'm mistaken they are cleaned up properly, see Q_GLOBAL_STATIC
>> and the Qt source for how that works. The thing is that they are cleaned
>> up "pretty late" and thus often are reported as memory leaks.
>>
>> Andreas
>>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 13 in thread
On 07.07.07 22:43:09, David Forstenlechner wrote:
> I see,
> the globals using Q_GLOBAL_STATIC have a mechanism to be cleaned up
> before shutdown,
> is there a way to trigger the deletion of the globals explicitly?
No, thats not possible by design, these globals are needed until they
are cleanup with the current mechanism. Its not possible to clean these
up earlier.
Andreas
--
[ signature omitted ]
Message 14 in thread
No problem,
the globals are no difficulty for the memory leak detectors,
the memory allocated for the current thread and some locale
stuff is not cleaned up, these are the leaks I see in the simple
example I posted at least.
DavidF
Andreas Pakulat wrote:
> On 07.07.07 22:43:09, David Forstenlechner wrote:
>> I see,
>> the globals using Q_GLOBAL_STATIC have a mechanism to be cleaned up
>> before shutdown,
>> is there a way to trigger the deletion of the globals explicitly?
>
> No, thats not possible by design, these globals are needed until they
> are cleanup with the current mechanism. Its not possible to clean these
> up earlier.
>
> Andreas
>
--
[ signature omitted ]
Message 15 in thread
On Saturday 07 July 2007 20:01:03 David Forstenlechner wrote:
> I tried both, boost unit test and Boundschecker and get 7 memory
> leaks reported with a single line test program like
>
> main(int argc, char* argv[])
> {
> QCoreApplication app(argc, argv);
> }
>
Valgrind (from linux) reports that test as clean.
==1687== LEAK SUMMARY:
==1687== definitely lost: 0 bytes in 0 blocks.
==1687== possibly lost: 0 bytes in 0 blocks.
==1687== still reachable: 11,085 bytes in 143 blocks.
==1687== suppressed: 0 bytes in 0 blocks.
Are you sure that Boundschecker doesn't (errornously) report reachable blocks
as leaks? There is little point in deallocating memory if you are about to
call exit() anyway :)
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
