>> We're lured into the impression that HBQT doesn't leak memory.
>> I say this because HBQT in dynamic mode doesn't seem to be
>> using our memory allocation functions at all, so nothing is
>> tracked, which means we're getting a constant zero leak
>> whatever is happening inside HBQT.
>> Do you have any suggestions to how to force C++ to use our
>> own memory allocation function, or where to look for a solution?
>
> In Linux you can use valgrind to check memory leaks.
> Just simply run:
> valgrind --tool=memcheck --leak-check=yes -v ./demoqt 2> demoqt.log
> and check the memory allocated and not released. If you compile Harbour
> with -g GCC option (HB_USER_CFLAGS=-g) and not strip final binaries
> then you will also have exact line number information. It's much more
> precise information then in our own memory statistic module.
> I think that you can also find some tools to test allocated and
> not freed resources for MS-Windows (i.e. Pritpal was using sth like
> that when he reported that HVM do not destroy internal mutexes on
> exit) though probably the reports will not be very precise.
The only "problem" with valgrind is that it doesn't work
on Windows, and most QT developers use Windows. Otherwise
it's indeed the best tool.
>
> In fm.c we have code to overload C++ new operators but it's enabled
> only when core code is compiled in C++ mode. If you want to enable
> it in all HBQT builds then these code should be moved to one of it's
> .cpp files which is always linked. It's not very elegant but it should
> work.
Damn. You're right, and I have even been there several times.
I'm thinking of two solutions.
1) Add these override methods to HBQT. I fear that it will
collide if we will have any other C++ libs in the pack.
2) Add an extra Harbour core lib named hbcpp (f.e.) and
build that in forced C++ mode for all targets.
This poses a problem when given target doesn't
support C++ mode.
> Alternatively we can try to use dlmalloc as full replacement for
> standard malloc()/calloc()/realloc()/free() functions and report
> info all memory blocks not freed after HVM exit. This is the most
> often used method in different devel tools catching memory leaks.
> To minimize number of modifications and keep our own FM logs we
> can also use dlmalloc with USE_DL_PREFIX and create our own wrappers
> to above functions, i.e.:
> void * malloc( size_t size )
> {
> return hb_xalloc( size );
> }
> void * calloc( size_t size )
> {
> void * ptr = hb_xalloc( size );
> if( ptr )
> memset( ptr, 0, size );
> return ptr;
> }
> [...]
I can't oversee this solution, but for me it's good.
Next question: What to do now?
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
