An even simpler one:---
PROCEDURE Main()
LOCAL oBrowse, tmp
oBrowse := TBrowseNew( 0, 0, MaxRow(), MaxCol() )
oBrowse:addColumn( TBColumnNew( "a", {|| "b" } ) )
tmp := oBrowse:getColumn( 1 )
tmp := oBrowse:colWidth( 1 ) + Len( oBrowse:colSep )
RETURN
---
Brgds,
Viktor
On Wed, May 13, 2009 at 9:42 PM, Viktor Szakáts <harbour...@syenar.hu>wrote:
> Hi Przemek,
> I could reduce the bug to this small example, important that
> it only happens with -gc3:
> ---
> PROCEDURE Main()
> LOCAL oBrowse, tmp
>
> dbCreate( "test.dbf", { { "FIRST", "C", 10, 0 } } )
>
> USE test.dbf
>
> oBrowse := TBrowseNew( 0, 0, MaxRow(), MaxCol() )
>
> oBrowse:addColumn( TBColumnNew( "FIRST", {|| FIELD->FIRST } ) )
>
> tmp := oBrowse:getColumn( 1 )
> tmp := oBrowse:colWidth( 1 ) + Len( oBrowse:colSep )
>
> RETURN
> ---
>
> Result:
> ---
> Error BASE/1301 Object destructor failure: Reference to freed block
> Error BASE/1301 Object destructor failure: Reference to freed block
> ---
>
> Brgds,
> Viktor
>
>
> On Wed, May 13, 2009 at 5:11 PM, Viktor Szakáts <harbour...@syenar.hu>wrote:
>
>> Hi Przemek,
>> I can now consistently replicate the problem with latest Harbour
>> build, smaller app, also with MinGW and under Linux/gcc. Now I'm doing
>> tests with valgrind, but it doesn't signal anything interesting.
>>
>> Can you suggest a valgrind command line which could help
>> locating such problem? or any non-valgrind method?
>>
>> Brgds,
>> Viktor
>>
>> On Mon, May 11, 2009 at 8:52 PM, Przemyslaw Czerpak <dru...@acn.waw.pl>wrote:
>>
>>> 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
>>>
>>
>>
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
