Miguel, Brian's company (http://www.AbacusLaw.com) publishes a very big xHarbour FWH application, with similar structure as you describe. Brian uses a test program to run the application through a testing script, which opens and closes all Windows repeatedly. It's been many years now that the test runs for hours without any noticeable memory leak.
Do you use any C code, except FWH? What about DLLs, OLE, etc? Ron On Apr 17, 2008, at 2:38 PM, Miguel Angel Marchuet wrote: > I'm using the xharbour function Memory( HB_MEM_USED ) to get the Items > this functions shows me that all items are never free. (Task > manager only confirm the situation) > > We make the next operation to test, we open 10 MDI child windows > with folder with 4 to 8 dialogs each one. > then we close all windows and repeat this operation. aplication > grows 5 to 8 Mg each 10 windows Open and close. > > We stop test at 350Mg and 1Gb of virtual memory. > > We don't know were is the problem, the most hight possible is > problem of FWH. but we can't see all FWH code. > But is possible too array problems.... > > This type of windows is an object with an array of controls than > contain objects (windows too) with an array of objects ... as you know > > MDI CHILD - ARRAY OF CONTROLS - FOLDER - ARRAY OF DIALOGS - ARRAY > OF CONTROLS - CONTROL - ARRAY OF CONTAINED CONTROLS > > When we try to free the MDI CHILD not all HB_ITEMS are free ( same > problem at [x]Harbour ). > > Best regards, > Miguel Angel Marchuet > > Ron Pinkas escribió: >> Miguel, >> >> Memory consumption reported by Windows, can be very misleading. >> F.e. just MINIMIZE your application, and then check the >> consumption in the Task Manager. You'll see that after your app is >> MINIMIZEd Windows will suddenly report the release memory which >> was freed by the application. >> >> Ron >> >> On Apr 17, 2008, at 1:54 PM, Miguel Angel Marchuet wrote: >> >>> 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 >>>>>> xHarbour-developers@lists.sourceforge.net >>>>>> 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 >>>>> xHarbour-developers@lists.sourceforge.net >>>>> 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 >>> xHarbour-developers@lists.sourceforge.net >>> 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 xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
