Hi Pritpal,
I'm facing the same issue with xhgtk library, it's basically the same thing
except that I'm using with the Browse Class.
Here's the error message:
Error BASE/1301 Object Destructor Failure: Reference to freed block
BASE/1301 Object Destructor Failure: Reference to freed block
Total memory allocated: 557807 bytes (4590 block(s))
WARNING! Memory allocated but not released: 36 bytes (1 block(s))
fm.c:623: HB_TR_ERROR Block 1 (size 32) XHGTK_TREE_ITER_NEW(0), "08,8.900/8-
E.9000000000000000E00*91723)9-0.A.F000200000002000000"
Even removing the destructor clause and put the call to xhgtk_tree_iter to
the "destroy" event through the callbacks, I got this error above
Regards
Rodrigo Moreno
On Feb 12, 2008 6:19 PM, Pritpal Bedi <[EMAIL PROTECTED]> wrote:
>
> Hello
>
> This observation pertains to non-freeing of mem blocks.
>
> While investigating deep I found yet another surprise ( or I am
> underinformed ) or it is supposed to behave the same way as is happening.
>
> You need to link the sample below with FreeWin.lib as it was quick to use
> that engine to create a modeless window having its own event management
> but
> invoked off a GTWVT application.
>
> Function Main()
> Local nSel
> Local aSel := { 'Execute Modeless Window', 'Exit' }
>
> SetColor( 'N/W' )
> CLS
>
> do while .t.
> nSel := AChoice( 10,30,15,60, aSel )
> if nSel == 0
> Exit
> endif
> ExecModelessWindow()
> enddo
>
> Return nil
>
> Function ExecModelessWindow()
> Local oWnd
>
> oWnd := CWindow():New()
> oWnd:ShowWindow()
>
> Return NIL
>
> Try to execute few window one after the other as control returns back to
> do
> while loop. Everything will go normal. Close all windows and exit the
> application. Check FM.LOG. It will have an array of unfreed memory blocks.
> Also inspect the task manager with opening of each window. Memory goes on
> increasing and never decreases. Instead of FreeWin.lib you can test it
> with
> your own library, the only condition is that application be a GTWVT ot
> GTWVG
> linked one and window be invoked from within this executable.
>
> Yet more ineteresting: Just open one window and move the mouse over it and
> over application window for some time and check the fm.log. You will find
> a
> long list of entry like:
>
> Block 469 001EDB50 (size 40) INKEY(0),
>
> "B0C21D00C0DA1E00184143000100000002000000000000000A000000820000000000000000000000"
>
> My point is, is there any way to release memory occupied like this? Note
> that <Local oWnd> get out of reference once <Return NIL> is encountered
> but
> the code assigned to oWnd via CWindow() class keeps on working without any
> errors.
>
> Regards
> Pritpal Bedi, INDIA-USA
>
> --
> View this message in context:
> http://www.nabble.com/GC---Reference-to-Freed-Memory-Block---GPF-tp15403015p15441969.html
> Sent from the Harbour - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
