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 >>>>> [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 >> > > > > __________ 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
