Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-12 Thread Pritpal Bedi
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

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-12 Thread Pritpal Bedi
Hello All In quest of finding the root of this bug, I tried to eliminate the addons one-by-one. First step was to disable GTWVG specific GUI stuff. And the error comes right after some actions just before I ask for first GET. Here it is:

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-12 Thread Rodrigo Miguel
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

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-11 Thread Pritpal Bedi
Hello Przemek Przemyslaw Czerpak-2 wrote: Clipper does not have destructors and xHarbour cannot detect most of destructors errors at all what causes memory corruption and later GPFs. See tests/destruct.prg as an example of such errors. It also illustrates why destructors are not safe in

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-11 Thread Przemyslaw Czerpak
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

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-11 Thread Przemyslaw Czerpak
On Mon, 11 Feb 2008, Randy Portnoff wrote: Hi Przemek, I just took a look at (what I think is) the latest build on SourceForge and I do not see that HB_GCALL takes any parameters - Are you sure there is a difference between hb_gcAll(.t.) and hb_gcAll()? In Harbour there is no difference at

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-11 Thread Mindaugas Kavaliauskas
Hi, 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 */

Re: [Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-11 Thread Przemyslaw Czerpak
On Tue, 12 Feb 2008, Mindaugas Kavaliauskas wrote: I'm not sure we are talking about the same thing, but if memory are dumped to fm.log files, I have a little proposition how to extend output to help find memory leaks. It was not the same thing though maybe address information will help

[Harbour] GC - Reference to Freed Memory Block - GPF

2008-02-10 Thread Pritpal Bedi
Hello Everybody I receive this error when executing modules with parent/child relations. Child records are shown in a TBrowse. //// ErrorSaver: This runtime error loged on 10/02/08 at 12:34:33 hrs User : SUPERVISOR Application: Demo