On Mon, 11 Feb 2008, Pritpal Bedi wrote:
> I have understood in what circumstances destructors operate. But I have
> never used destructors anywhere. I mean I am not assigning self to any class
> variables, public variables, or even I do not use DESTRUCTOR command in any
> of my classes. Because my application distribution still support Clipper
> compiled exe, I have ever tried to keep code as near to Clipper as possible.
Then the bug can be anywhere in some C code you are executing or in
foreign code destructors. IMHO it's rather C code which corrupts memory
or some code borrowed from xHarbour which operates on HB_ITEM directly
at C level. F.e. good example of such code is old hbziparch, f.e.:
proc main()
HB_UNZIPALLFILE(,,,,,"",{||nil})
return
The same bug exists in Harbour and xHarbour but only Harbour reports it.
But it can be result of any memory corruption, f.e.:
proc main()
BADCFUNC({})
return
#pragma begindump
#include "hbapiitm.h"
HB_FUNC( BADCFUNC )
{
/* damage 1-st param item type */
memset( hb_param( 1, HB_IT_ANY ), 0, 4 );
}
#pragma enddump
Here also only Harbour GC can detect such situation and xHarbour
(and probably also Clipper but I haven't tested) will not report
any errors.
As you can see _ANY_ buggy C code can cause such error.
The problem is to find it. And it's rather very important
thing if you noticed sth like that to locate the exact reason
not only find workaround because memory corruption errors can
cause any other unpredictable bugs later in different places.
> The code has been and is working ok since 15 years.
Clipper is used by people for really long time with success but
we know that it has some memory corruption bugs. It does not mean
anything.
> The problem is more I try to isolate the bug, more I get confused. I comment
> out one branch, say this browser execution, the error shifts and surfaces
> somewhere else. Because it is there in inkey() function which is used
> heavily in all corners, I am not been able to isolate. I issue hb_gcall( .t.
> ) at few places and all those occurances are somewhere before inkey() calls.
> Can you point out, or provide, some mechanism to handle this situation, or
> to trace it more deeply ?
I suggested to use hb_gcAll(.t.) as replacement for hb_inkey(n) only
not to fix anything. Both execute GC cleanup code but hb_gcAll(.t.)
without delay.
To isolate the problem you will have to strip down your application
removing all executed code and modules to exclude also startup/init
code until you will not find the place which is source of the problem.
You should finish with small example. It's possible that using CodeGuard
or valgrind can help in locating bug. Both can detect many memory
corruption errors but not all.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
