Submitted by Anonymous on Sat, 04/27/2002 - 23:23. Developers
Hi, this is John Hendrickson.
Memory climb in XmContainer / Icongadgets.
The app (fm) allocates and deallocates Icongadgets for a persistent container. As the app runs memory climbs (in both my version and origional version). After [free] are done only smaller ammounts are released (thus the climb). (Note I used `gtop` or `gps` to watch memory.)
Here`s a layout
WidgetList XmList IconGadgets ; /* persistent */
IconGadgets = (Widget *) XtMalloc (sizeof (Widget) * newsize ) ; /* persistent */
/* per viewed directory; icons currently unmanaged */
/* begin */
IconGadgets[counter++] = XmCreateIconGadget (container, "IG", NULL, 0 );
details[num_details++] = XmStringCreateLocalized (user->pw_name);
*icon = XmGetPixmap (XtScreen (toplevel), str, fg, bg);
*mask = XmGetPixmapByDepth (XtScreen (toplevel), msk, fg, bg, 1);
stemp = XmStringCreateLocalized (filename);
XmStringFree (stemp);
XtVaSetValues (IconGadgets
, XmNentryParent, parent_folder,
XmNoutlineState, XmCOLLAPSED, XmNlabelString, stemp,
XmNlargeIconPixmap, icon, XmNlargeIconMask, mask, XmNsmallIconPixmap,
s_icon, XmNsmallIconMask, s_mask, XmNdetail, details, XmNdetailCount,
num_details, NULL, NULL) ;
for (i = 0; i < num_details; i++)
XmStringFree (details[i]);
/* effect a view update */
fixViewerSize (XtParent (fileviewer), NULL, NULL);
XtManageChildren (pv->IconGadgets, pv->validIcons);
/* handle user requests .. wait for next directory */
/* next directory ... first deallocate old IconGadgets */
XtUnmanageChildren (IconGadgets, validIcons);
XtDestroyWidget ( IconGadgets[ --counter ] );
IconGadgets[ counter ] = NULL;
/* goto begin */
As far as I`ve read I`ve done all the deallocations I`m expected to. I`m not 100% sure about what XtVaSet might do that should be undone.
I`m using both `gtop` and `gps` to look at the climb (I know - not exact tools). Memory starts at about 2MB and after a several thousand IconGadgets (say, a several hundred per directory and browsing many directories) climbs to 8MB. So the climb is significant if `gtop` is telling the truth.
Thanks,
John Hendrickson
P.S.
(I`m revamping filemanager demo as a learning project - incl. the tutorial aspect of it. Its coming along nicely. It now has two independant view, otherwise looks the same but works allot like it looks.)
(sparky not like `radar` from mash or Sparc. Once I installed an HD for a drive-drive copy. My power supply cabel wasn`t long enough so borrow power from the computer next to it (same voltage, right?). Sparks flew from the HD and it cracked a chip, and the computers name was dubbed `sparky`. (It still works - minus the HD I returned).
)
This is the `right` thread
Hi all,
dbl [or whoever posts]
I looked at the source for IconGadget. It releases the GCs and destroys, pixmaps, labels, and finally (?part) of the XmCache. It all looks good to me so I`m not sure whats going on.
NOTE their are *two* identifiable memory climbs.
1) The first occurs during XtVaSetValues (a large ammt. of memory is allocated than freed) that sets the values for IconGadgets. I can beleive that Xt is allocating memory for details and that I`m not freeing it. But I have no clue.
2) When XmContainer manages the icons for the first time in the view (due to re-order, resize,...). Again, at the first XtManageChildren (pv->IconGadgets, pv->validIcons); their is a memory climb that also is not fully freed later. HOWEVER, I just tried and found the RE-managing icons has no effect whatsoever on memroy.
ALSO the memory climb is much smaller if I use unspecified pixmap for all icons. But to my knowledge - the pixmap feature is fine? Allocating an icon *should* increment the pixmap held value in the cache if its already been read, decrement the counter on release, and of course delete the pixmap when the count is zero.
I read the memory management post recently posted. I`m XmDestroying Icongadgets. Is there any heirarchial Xtdestroying per IconGadget that I should be aware of? I`m only aware that XtDestroyChild calls only the Destroy mapped in for each IconGaget, right?
I`m *assuming*
XtDestroyWidget (pv->IconGadgets[i]);
calls (IconG.c) Destoy and also destroys widget after all the other deallocations.
Anyway, and help would be much appreciated,
John Hendrickson
Are you sure that you are handling the variable "IconGadgets" correctly i.e. using XtFree() when you need to and not accidentally reallocating it on every entry into this code?
And there does seem to be a problem -- you XmStringFree(stemp) before you use stemp.
(the xmstringfree(stemp) was a cut/paste snafu and not actually in the code. I`m using OpenMotif 2.2 under Debian r2.5 stable)
Wait... one more "indication". As the memory climbs, it takes longer and longer to update the view (manage icons). Its as if either Xt, XmContainer, XmIconGadgets, or XmCache is traversing a list of all [objects] even though supposedly XmDestroy has `unhooked` them. ??
I was being simple saying IconGadgets is persistent. If the number of Icons > maxIcons then a reallocation is done. However - I do have an `option` that deallocates all IconGadgets and XtFrees the IconGadgets memory pointer for every directory which had been to `fix` this. But it has the same memory climb too.
I know what you mean If I reallocate IconGadgets its pointer [may] change. Any place in the code that stores the pointer would then be adding offsets to the old and wrong pointer. Check.
I fprint all allocations/deallocations neatly so as to the the control logic (when & which widgets) I am sure. Anyway - it segfaults whenever I botch the allocations / deallocations so I find out pretty quick due to the size and variety of linux directories.
And that is interesting misallocations cause seg faults. But I don`t get seg faults when all else is ok. But I do get memory climb and ever longer mange-icons.
Infact I`d rather not ask questions like this. I`ve coded in one language or another for almost 15 years. I have a science degree - and don`t like *giving in* )
----------------------------------------------------------
But realistically my next step is to start adding debugging to my copy of IconG.c, Container.c, ... (put in fprintf`s to see what pointers are lying around, how many icons are in the loop, etc.) I`m out of `tweaks` to try.
All I *can* say that might ring a bell is that their is a pause when going from a large directory to a small one and the mouse cursor blinks during it. (and again, as memory climbs managing icons takes longer and longer, and no matter what memory allways climbs).
Its still `filemanager` - an `OpenMotif` demo to be, I hope. I was going to send you a diff when done. If you want I can email the current project.
Thanks allot for the time you spend on answering the questions in [your] MotifZone !!
John Hendrickson