On Mon, 11 May 2009, Szak�ts Viktor wrote:

Hi,

> I just received this error in my otherwise stable app:
> Error(2) BASE/1301 Object destructor failure: Reference to freed block
> Then it gave an MSVC RTL error message, finally a
> regular app crash (but without logs).
> This happened with an MSVC 2005 build, rev 10222, in
> an hb_idleSleep() call, after leaving the app running for
> hours, most of the time idling with a screen saver and
> playing with it for a few minutes. The error happened
> when trying to exit to idle app. This also means I cannot
> create a small example to replicate the error.
> Is there anything I can do to track this down, or other
> ideas why could this happen?
> [ The app uses some private C code, but only simple
> function calls and it also does some GC collected
> allocations in gauge/file viewer functionality. ]

hb_idleSleep() can activate the GC so it can be shown in call stack
but the problem is not in this function but somewhere else, probably
in your local code but I can only guess. Harbour counts all GC allocations
and deallocations and if they are not equal or when destructor reattach
destroyed block to known item which is not destroyed in the same pass
then above RT error message is generated.
It can be caused by stupid typo like dummy hb_gcAlloc() call without
attaching the result to know for HVM HB_ITEM, f.e.:

   proc main()
      f()
      hb_idleReset(); hb_idleSleep(1)
   return
   #pragma begindump
   #include "hbapi.h"
   HB_FUNC_STATIC( F ) { hb_gcAlloc( 10, NULL ); }
   #pragma enddump

or it can be sth more serious like result of some memory corruption, f.e.:

   proc main()
      f( {} )
      hb_idleReset(); hb_idleSleep(1)
   return
   #pragma begindump
   #include "hbapi.h"
   HB_FUNC_STATIC( F )
   {
      PHB_ITEM pItem = hb_param( 1, HB_IT_ANY );
      /* simulate memory corruption */
      memset( pItem, 0, 4 );
   }
   #pragma enddump


What exactly happen in you case I do not know. I can only tell you that
one memory blocks allocated by hb_gcAlloc():
   1. was not attached to know item at all
or:
   2. it was reused and attached to new item after destroy (hb_gcFree())
or:
   3. the reference counter to such memory block (or item which kept such
      reference counter) had been corrupted (overwritten) by some buggy code.

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to