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
