On Mon, 04 Jan 2010, Szak�ts Viktor wrote:

Hi,

> 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.

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.

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;
   }
   [...]

best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to