Yes, the problem with our TACTIVEX class is solved now, and others GPFs. ;)
I hope not find any other GPF in a long time. Rare something was happening and I need to check if the problem persists. Debugger of the Borland showed a stack of calls incorrect when there was a GPF, this happened when it created definitions of functions between methods of a class. The stack showed the first function that nobody had called, but seemed to run the correct method apparently. Rare !!!! There is only one problem that remains is that the memory consumption of our applications ups without stopping, to consume the entire system. After a long performance. And that we try to reuse to maximize resources, loading once bitmap and fonts, and where possible the DIALOG and WINDOWS, but little by little is lost memory. Not released all HBITEM reserved: (Finding the problem is the work of Chinese) . May be the problem in a 3rd party library (FWH) but can also reside in the kernel xHarbour. Harbour has the same problem although it consumes less memory. Our application with xHarbour consumes 9.4Mg at start and only 9Mg with harbour. But finally two compilers has the same problem there are HB_ITEMS not free never.... I we have a tool similar to roolback of SQL for example GC_START() => GC_POINTER GC_STOP( GC_POINTER ) GC_CONTINUE( GC_POINTER ) GC_FREE( GC_POINTER ) to free all items created in this interval of time with this we can solve 3rd party library problems What do you think about ? Best regards, Miguel Angel Marchuet Ron Pinkas escribió: > Miguel, > > Did you also solve the OCX problem? > > Ron > > On Apr 17, 2008, at 10:03 AM, Miguel Angel Marchuet wrote: > >> With this CVS seems all ok, without GPF :) >> >> Many thank's >> >> Best regards, >> Miguel Angel Marchuet >> >> Ron Pinkas escribió: >>> 2008-04-16 15:30 UTC-0430 Ron Pinkas <ron/at/xharbour.com> >>> * include/classes.h >>> * source/vm/classes.c >>> + Added hb_clsDisableDestructors() and hb_clsClearAll() >>> + Added logic to raise internal error if Destructor encountered >>> after Destructors can no longer be executed >>> >>> * include/hbapi.h >>> * source/vm/memvars.c >>> + Added hb_memvarsClear() >>> >>> * source/vm/hvm.c >>> * Cleaned hb_vmQuit() shutdown order, and use new: >>> hb_clsDisableDestructors(), hb_clsClearAll(), and hb_memvarsClear() >>> to guarntee that all prg data is cleared before any C >>> subsystem is released. >>> >>> /* >>> I'm not sure why we had a comment stating that Destructors >>> should not run after STATICs have been released >>> it suggested possibility of Destructor activating DBG code >>> which may use STATICs, but the Debugger is already >>> deactivated at that point. >>> >>> I added 2 #ifdefs to allow disable of Destructors before >>> release of STATICS >>> as well as before release of prg data in class definitions (f.e >>> INIT values). >>> >>> >>> #ifdef DISABLE_STATIC_DESTRUCTORS >>> #ifdef DISABLE_DATA_DESTRUCTORS >>> >>> Otherwise xHarbour now gurantees execution of all Destructors. >>> */ >>> >>> >>> >>> ------------------------------------------------------------------------- >>> >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >>> Don't miss this year's exciting event. There's still time to save $100. >>> Use priority code J8TL2D2. >>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >>> >>> >>> _______________________________________________ >>> xHarbour-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/xharbour-developers >>> >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> >> >> _______________________________________________ >> xHarbour-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xharbour-developers >> > > > > __________ Información de NOD32, revisión 2701 (20071204) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ xHarbour-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xharbour-developers
