GUI Seperation from the Application Process
sujeet
We have a process whose size increases and performs badly due to motif
memory leaks,
so we have decided to create a independent process which will handle
GUI,
and this process will communicate with the application via IPC.
so the widget overhead on the application is reduced,
pls let me know if this is goining to help.
Has anyobdy done this before????..
Thanks,
Sujeet Jog
Aaron W. Hsu
>We have a process whose size increases and performs badly due to motif
>memory leaks, so we have decided to create a independent process which
>will handle GUI, and this process will communicate with the application
>via IPC. so the widget overhead on the application is reduced,
I do not know what specific memory leaks you have, but I doubt this will
help unless you intend to restart the GUI server occassionally. However,
this means you'll have to recreate the whole GUI again. I think it would
be better to just hunt down your leaks and make sure you know that they
are coming from Motif. Then you can patch them up.
Even if you isolate the GUI, the memory leaks would still be there, so
you aren't saving yourself anything. That is, if I understand you
correctly, I doubt this will help with your specific leakage problem.
--
Aaron W. Hsu <arc...@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
arahne
> HI Friends,
>
> We have a process whose size increases and performs badly due to motif
> memory leaks,
> so we have decided to create a independent process which will handle
> GUI,
> and this process will communicate with the application via IPC.
> so the widget overhead on the application is reduced,
If you are using latest version of OpenMotif, then it is highly probable
that the memory leak lies elsewhere.
http://www.motifzone.net/
http://sourceforge.net/cvs/?group_id=220144
Note that memory leak in Motif GUI within your application, and memory
leak in Motif library, are not the same thing.
In any case, it is easy to check with Valgrind
http://valgrind.org/
to see if Motif library is leaking or your application.
Just run the debug version of your program with
valgrind --leak-check=full program_name
And if Motif is the reason, it is much easier to plug the memory leak,
than to rewrite your program in two processes with IPC communication.
You can report the bug here, and if is serious, it s likely it will be
fixed withing reasonable time.
http://bugs.motifzone.net/
Anyway, OpenMotif is open source, so it is also possible for you to fix
the memory leak, and share the fix with the rest of the community.
> pls let me know if this is goining to help.
> Has anyobdy done this before????..
I am sure this architecture was used before, but probably for some other
reasons, not to plug the memory leaks. It would only help with memory
leaks, if the GUI part of application would be restarted periodically,
while the main application would still be running.
Best regards,
Dušan Peterc
http://www.arahne.si
Aaron W. Hsu
>Are you 100% sure motif is the reason?
>If you are using latest version of OpenMotif, then it is highly probable
> that the memory leak lies elsewhere.
>http://www.motifzone.net/
>http://sourceforge.net/cvs/?group_id=220144
I was under the impression that OpenMotif 2.3 was much less stable than
the Official OSF Stable release 2.1.30p5 and the IST versions. Does this
not hold true for the memory manamagement? Are there known leaks in the
2.1.30 source that have been fixed in the 2.3 versions of the code?
arahne
> I was under the impression that OpenMotif 2.3 was much less stable than
> the Official OSF Stable release 2.1.30p5 and the IST versions. Does this
> not hold true for the memory manamagement? Are there known leaks in the
> 2.1.30 source that have been fixed in the 2.3 versions of the code?
>
I think that a big number of bugs has been fixed.
ftp://ftp.ics.com/openmotif/2.3/2.3.1/RELEASE
and at least one of them is a memory leak.
http://bugs.motifzone.net/show_bug.cgi?id=1377
Otherwise, not to repeat myself too much, memory leaks are not a matter
of opinion. Test the program with Valgrind, and you will know.
Valgrind will report the line of the error, which will be either
in your code, or in the library.
My application with 5000 widgets and over 100.000 lines of source code
does not have memory issues. The only "memory leaks" are related to use
of antialiased (XFT) fonts, where XFT library does not free the
allocated fonts, due to its internal font caching strategies.
If you don't use antialiased fonts, you are not affected by those.
These are the fixes in the ICS version of Motif, which has not been
updated in the last 4.5 years.
http://www.ist.co.uk/motif/motif_changes.html
In my opinion, the ICS version of Motif is not useful for new
development, without antialiased fonts, UTF-8, native JPEG/PNG support,
and alpha channel pixmaps.
Aaron W. Hsu
>Aaron W. Hsu wrote:
>> I was under the impression that OpenMotif 2.3 was much less stable than
>> the Official OSF Stable release 2.1.30p5 and the IST versions. Does this
>> not hold true for the memory manamagement? Are there known leaks in the
>> 2.1.30 source that have been fixed in the 2.3 versions of the code?
>I think that a big number of bugs has been fixed.
>ftp://ftp.ics.com/openmotif/2.3/2.3.1/RELEASE
>and at least one of them is a memory leak.
>http://bugs.motifzone.net/show_bug.cgi?id=1377
It is nice to see that a few of the leaks have been fixed. My own search
confirms this in a few respects. I wonder about how much they have
changed though.
I believe we have discussed this in the past, looking at the archives. I
still am not convinced, seeing as how OSF hasn't done anything to
acknowledge OpenMotif 2.3, and even takes the time to state that they do
not endorse the work (despite ICS being a maintenance partner) produced
by these other companies.
Actually, in this respect, I kind of think that Motif is in a bit of a
mess, despite it being a perfectly capable system. I don't like how the
three organizations involved in Motif don't seem to be able to get along
well enough to stabalize things beyond 2.1.30.
>These are the fixes in the ICS version of Motif, which has not been
>updated in the last 4.5 years.
>http://www.ist.co.uk/motif/motif_changes.html
>In my opinion, the ICS version of Motif is not useful for new
>development, without antialiased fonts, UTF-8, native JPEG/PNG support,
>and alpha channel pixmaps.
I believe you mean the OSF/OpenMotif version. However, in my readings,
it appears that many of the features of 2.3 are redundant and useless
bloat, at least according to Antony Fountain:
Besides, its entirelty possible to make Motif do all kinds of
things: from simple things like making the text have multiple
coloured selections or providing tooltips, through to UTF-8 font
support and section 508 accessibility can be done via shared
library plug-ins without modifying the Motif 2.1.30 sources one
jot.Motif 2.1.30 is a mighty powerful release. It doesnt need
new widgets: the ones it has are perfectly fine and generic, and
anything else tends to be domain specific, which isnt what a GUI
toolkit is about. And since there are plenty of plug-in
components that are compatible and mature that can be had from a
variety of sources, anything domain specific can be downloaded
easily enough. Nor does it need two comboBoxes, two panes, two
toggles, ..., despite what ICS may think. Any additions simply
turn the toolkit from a platform-independent vendor-neutral
generic toolkit into one fit for only one specific purpose and
platform, or work with only one proprietry GUI builder.
But since this seems to have been discussed plenty already, and is in
the archives, I'll just let it be.
markj...@gmail.com
> arahne <ara...@arahne.si> writes:
> >Aaron W. Hsu wrote:
> >> I was under the impression that OpenMotif 2.3 was much less stable than
> >> the Official OSF Stable release 2.1.30p5 and the IST versions. Does this
> >> not hold true for the memory manamagement? Are there known leaks in the
> >> 2.1.30 source that have been fixed in the 2.3 versions of the code?
> >I think that a big number of bugs has been fixed.
> >ftp://ftp.ics.com/openmotif/2.3/2.3.1/RELEASE
> >and at least one of them is a memory leak.
> >http://bugs.motifzone.net/show_bug.cgi?id=1377
>
snip>
Hi,
I am part of the OM 2.3 team and if you do find a memory leak, we
would really like to have it reported in bugzilla so we can fix it.
That goes with any other bugs you might find too.
Cheers,
Mark
Fred
I have found that Motif itself has very few memory leaks. Most often
what
seems like a memory leak in Motif is actually due to incorrect usage
of
Xt or Motif functions. The most common seem to be:
1) Failing to free XmStrings. This often occurs in code like this:
XtVaSetValues( widget, XmNlabelString, XmStringCreateLocalized
(...), NULL);
XmStringxxx functions should never be used as arguments to a
function.
2) Failing to free the values retrieved from calls to XtGetValues().
Remember, for most pointer resources (Striings, XmStrings, etc.) ,
a pointer to a new copy is returned.
--
Fred K
Bill
==7217== 629,328 bytes in 25,964 blocks are definitely lost in loss
record 490 of 499
==7217== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==7217== by 0x651781: XQueryTree (in /usr/lib/libX11.so.6.2.0)
==7217== by 0x4159DAA: XmGetVisibility (Traversal.c:1493)
==7217== by 0x415A06F: IsTraversable (Traversal.c:1335)
==7217== by 0x415B323: XmeNavigChangeManaged (Traversal.c:376)
==7217== by 0x40EF439: ChangeManaged (ScrolledW.c:3065)
==7217== by 0x5A162AB: (within /usr/lib/libXt.so.6.0.0)
==7217== by 0x5A16A49: XtManageChildren (in /usr/lib/libXt.so.
6.0.0)
==7217== by 0x5A16B24: XtManageChild (in /usr/lib/libXt.so.6.0.0)
==7217== by 0x40B85A7: SetHorizontalScrollbar (List.c:2920)
When XmGetVisibility calls XQueryTree in Traversal.c, it forgets
to free the list of children (see the XQueryTree doc in the Xlib
Reference Manual). (I'm guessing that is the problem -- I didn't
try to fix it).
arahne
First, when you should say which version of Motif/OpenMotif are you using.
Second, I think this bug has been fixed six years ago.
http://openmotif.cvs.sourceforge.net/viewvc/openmotif/openmotif/lib/Xm/Traversal.c?view=log
http://openmotif.cvs.sourceforge.net/viewvc/openmotif/openmotif/lib/Xm/Traversal.c?r1=1.4&r2=1.5
Motif is open source, in spite of what some license purists say.
So we should use the benefits of the source availability and cvs on
sourceforge and bugzilla.
http://bugs.motifzone.net/
Bill
I can't use the sourceforge version because they have thoroughly
broken
the paned window widget. Someday I'll file a bug report, and no doubt
you'll leap into the fray with some sanctimonious lecture.
arahne
I don't know how to reply without you perceiving it as a lecture.
Bill wrote:
> I'm using 2.2.3.
That means that the memory leak you reported has not been fixed in
correct way, as the fixes I mentioned from cvs are older than OpenMotif
2.2.3.
I am sure everyone will appreciate, if you file a bug report, and make
a small test case to demonstrate it.
> I can't use the sourceforge version because they have thoroughly
> broken the paned window widget.
If you are referring to this bug
http://bugs.motifzone.net/show_bug.cgi?id=1476
then it has been fixed two weeks ago.
http://openmotif.cvs.sourceforge.net/viewvc/openmotif/openmotif/lib/Xm/PanedW.c?view=log
I don't see any open paned window widget related bugs in the OpenMotif
bugzilla.
Note that I am not related with ICS in any way; I am just a user of
OpenMotif and wish to use a stable, bug free, and if possible slightly
evolving toolkit.
Bill
You're referring to Feb 19? I tried that version of motif on Feb 22.
It is hard to make a simple example, but I'll try to find time next
week.
Aaron W. Hsu
I didn't know anyone used 2.2 any more. Wow. :-) Is there some feature
of the paned window that isn't in 2.1.30? As I understand it, no one
considers 2.2 to be stable or very useful, and that you want to use
either 2.1.30 or 2.3, regardless. I wouldn't think that 2.3 would have
broken the paned window, but you're in trouble if your paned window
works only in 2.2 and not 2.1.30 or 2.3, IMO.
CVS has lot's of patches, so if there are patches that you need, you
might consider incorporating them into your source tree, even if you
don't want to move to the newer versions explicitely.