fong@OAHU.SEDD.TRW.COM (Jorge Fong) (10/12/90)
I have an application that needs to run 24 hours a day non-stop !!!
Every so often this application brings up a selection dialog box.
How do I destroy the widgets I have created in order to keep the process
size from growing monotonically forever.
Running Motif under HP-UX 7.0 on a HP 9000/370.
The code looks like:
XtSetArg(arglist[al], XmNmustMatch, must_match); al++;
dialog_box = XmCreateSelectionDialog (toplevel,"Selection_Box",arglist,al);
XtDestroyWidget(dialog_box);
If I run those 3 lines in an infinite loop, memory continues to be
allocated indefinetely.
Is it a Motif bug?
Is it an HP-UX bug ?
Thank You, Jorge Fongdbrooks@osf.osf.org (David Brooks) (10/13/90)
In article <9010121432.AA10860@BU.EDU> fong@OAHU.SEDD.TRW.COM (Jorge Fong) writes: > > I have an application that needs to run 24 hours a day non-stop !!! > > Every so often this application brings up a selection dialog box. > How do I destroy the widgets I have created in order to keep the process > size from growing monotonically forever. > > Is it a Motif bug? No. > Is it an HP-UX bug ? No. This, the grandaddy of all memory leaks, is in the Intrinsics. Unfortunately, it happens in accelerator table management, and Motif makes heavy use of accelerators behind the scenes. That's why it's not so obvious in the Athena widgets, for example. As far as we can see, it's been nailed in X11R4 fix-15/16/17 (which means Motif 1.1). Unless you have got this combination, the only solution is the proverbial "don't do that". For many, or even most, cases where people Create and Destroy dialogs, an acceptable alternative is to Create once, then to Manage and Unmanage. Also, it's preferable because it's more efficient. There are, however, some valid cases for create and destroy -- when the layout is unpredictable and varies wildly from instance to instance, for example. Not all Motif leaks have been fixed yet, but we are giving serious attention to them. We are even looking at Motif 1.0.3, and its enhanced version of the X11R3 intrinsics, with a view to fixing the Destroy leak there too. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks That last signature was getting a little tired...