Miguel: How long have you been having the memory issues with your app? I have not yet tested a build with recent cvs (last time was cvs from last October), but over the last several years we have watched this issue and have NOT had any memory leaks that were not fixed here on this list.
We have a FWH app with MDI child windows, and we cycle through opening and closing all 8 types of mdi children, plus opening modal dialogs in an automated test using what was MSTEST. So if you had this problem for a long time, I don't think it's FWH (although we do have altered versions of the Window classes, we stay close to Antonio's code). Get back to me on private email about this, and we'll compare approaches. Meanwhile I'll run the test on the current cvs build and see what's happening. -- Brian Hays > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Miguel Angel Marchuet > Sent: Thursday, April 17, 2008 2:38 PM > To: Ron Pinkas > Cc: xharbour-developers list > Subject: Re: [xHarbour-developers] 2008-04-16 15:30 UTC-0430 Ron Pinkas > <ron/at/xharbour.com> > > 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 > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.0/1383 - Release Date: > 4/17/2008 9:00 AM > ------------------------------------------------------------------------- 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
