radixii@grebyn.com (Radix II) (05/25/91)
BEWARE OF SCO, AND 'LEAKY' ODT, X & MOTIF
By
H. J. WALLACE and G. B. LAMERS
1.0 SCO AND ITS BUILT-IN GRAPHIC VIRUSES
Those who try to do some serious work with Motif 1.0 will discover (the
hard way) that the product contains a disastrous class of bugs; these bugs
are euphemistically referred to by the cognizati as 'memory leaks'. For
the benefit of the uninitiated, a 'memory leak' is a clumsy virus; its
first order effects are that memory requirements for an X/Motif program
grow without bound until the application finally devours itself and dies.
The higher order effects are, of course, enormous costs in wasted manhours,
aggravation, slippage in deliverables, customer dissatisfaction and loss
of business.
Even though this built-in virus is a severe and crippling defect, SCO
continues to sell the product to the suckers. For those who fell into the
SCO 'CGI-Trap' in the past (i.e., CGI applications also grow without
bound), the Motif 'leaks' will be a simple case of deja vu. As was true
for the CGI-'leaks', SCO Technical Support knows from nothing, and the
Company, in the best political tradition, adheres to the maxim that if you
ignore a disaster long enough, sooner or later it will be overtaken by
events and fade away --- (i.e., the Motif 'leaks' will follow in the
footsteps of the CGI defects, become a casualty of evolution, and simply
dissolve, over time, into cosmic indifference).
Since SCO's 'Technical Support' is no consolation, and while we all wait
for some other organization to fill the void created by SCO's lack of
customer orientation and quality control, it may be helpful to other
practitioners if we shared some of our experiences and recipes to plug
and/or work around the 'leaks.'
2.0 NATURE OF THE PROBLEM
For those who are considering to develop a real-time application under
SCO's ODT utilizing X and Motif, here is a simple experiment to convince
yourself that 'the product' is truly a joke and simply too costly for you
to afford:
a. create a Label widget;
b. change the Label widgets string once every few seconds using
XtSetValues;
c. let it cook for some hours.
Regardless of your hardware configuration, this trivial 'application' will
grow beyond bound and eventually use every byte of memory in your system.
If you do not want to wait for the final collapse of your machine, simply
execute a periodic ps -el and watch your application grow.
2.1 FEEDBACK FROM OTHER VICTIMS
When we first confronted the 'leak' problem, we contacted SCO and confirmed
that Technical Support knew from nothing. We then placed some messages on
the net. In spite of the fact that the various suggestions we received
did not disclose a solution, the feedback was nevertheless useful and
helped steer us in the right direction to bracket the problem.
Accordingly, a brief review of the feedback may be of some (historical)
relevance.
The inputs we received can be grouped into the following three general
categories:
a. The SCO Route: The universal suggestion was to 'pressure' SCO into
distributing Motif 1.1. Unfortunately, there are a few problems
with this suggestion:
1. Motif 1.1 requires X Release 4 (SCO only supports Release 3);
2. Motif 1.1 has improved the situation; it has, however, not
fully solved it.
b. Intrinsics Versus Motif: Some practitioners suggested that the
'leak' problems may reside in X Intrinsics. It is our conclusion
that 99% of the 'leaks' are caused by Motif.
c. Avoid Destruction: Another common suggestion was to never destroy
widgets; the idea is to create a widget the first time it is needed,
and to then re-use it when required.
Unfortunately, this advice is not an option for applications (i.e.,
Command and Control) in which continually changing (i.e., dynamic)
data need to be displayed each time a new window is opened.
As discussed in Section 3 below, it is indeed true that a major culprit
for the memory bugs is the widget destroy process. Unfortunately, widget
destruction is not the only thing that's 'leaking' --- the bug is also
rampant whenever the current content of a widget is changed.
2.2 THE POSITION OF SCO
After we convinced ourselves that Motif 1.0 is a non-product, SCO was
contacted again with a simply question, namely, what are the Company's
plans to plug the 'leak'. The answer we received was equally simple; the
highlights are:
a. SCO has no plans in the foreseeable future for any upgrade of MOTIF
1.0;
b. a new release of ODT will come forth in the near future;
c. the new ODT release will still contain the 'leaky' Motif 1.0.
In other words, SCO is again abandoning its customers and plans to continue
shipping junk.
3.0 SOME USEFUL AVOIDANCE PROCEDURES
The following may be helpful to others in the trenches out there who cannot
deliver a product for the simple reason that it has leaked itself to death
before it's out the door. Furthermore, if you have the source of Motif
(we, unfortunately, do not) it would seem to be a rather straightforward
exercise to plug (most of) the leaks.
RECIPE 1: Do not use XStringCreateLtoR to create compound strings for
widgets containing text. The problem is the following:
a. the procedure malloc's memory twice for each string;
b. the application has access to only one of the memory strings.
The end result is that every string invariably leaves behind 'lost' memory.
NOTE: XStringCreate is not contaminated and works properly. However, it
only creates single line strings. Therefore, if you need a
multi-line string, you must code your own.
RECIPE 2: When creating buttons and labels, there is a short-cut method
for creating the text string by simply using the widget name. DO NOT USE
THIS METHOD --- memory is lost every time. Instead, create the compound
string and set XmNlabelString yourself.
RECIPE 3: When destroying a List Widget, the 'leak' problems are
especially traumatic. Thus, in the destruction, first do XtFree on each
item in the List; then destroy the widget.
RECIPE 4: An alternate method to RECIPE 3 is to use XmListDeletePos to
delete each item in the list. This method recovers more memory than just
freeing the text strings. The difficulty is that the approach is slow to
the point of being unusable, unless there are very few items in the list.
(For example, on a 33 Mhz 386 with 16 MB, it takes minutes to destroy all
of the items in a list with 2000 items --- even though it only takes 3
seconds to create the same list.)
RECIPE 5: As is true of all destruction, memory 'leaks' come about when
destroying a Text Widget. Accordingly, obtain the text pointer from the
XmNvalue parameter and then use XtFree.
RECIPE 6: Memory 'leaks' are the invariable by-product whenever you change
text in a Label Widget. Accordingly, when changing the text, do not use
the XtSetValues procedure (the logical choice). Instead:
a. obtain the label string pointer from the widget using the
XmNlabelString parameter and XtGetValues;
b. free the compound String XmStringFree;
c. then use XtSetValues for the new text.
4.0 THE LAST REFUGE FROM THE 'CREEPING CRUDS'
If you have a real-time application that needs to run around the clock, 24
hours a day, 365 days a year, the recipes in Section 3 above help to
increase the relaxation time between consecutive system collapses --- they
do, however, not solve the problem.
In order not to look like an amateur to your customers, you can obviously
not tell them that you have shipped them an ODT platform characterized by
the 'creeping cruds'. Accordingly, we had no choice but to resort to a
camouflage of SCO 'leaks'; we call that camouflage 'System Maintenance'
(or 'SM' for short). Specifically:
a. the application continuously monitors the progress of the virus;
b. when a preset threshold is exceeded, we automatically:
1. pop up a (leaky) box and warn the user that we are ready to do
'System Maintenance' and that the process will take a few
minutes;
2. if the user is manning the screen, he/she is provided the
option to delay the ritual; ten minutes later, we try again;
3. when ready to do our 'SM-thing', we exit and then automatically
restart;
c. in addition we furnish a 'System Maintenance' button which we tell
the customer to press whenever the application appears to slow down.
If you have any followup comments, ideas, replies please send email to
radixii@grebyn.com
Oxon Hill Md. USArcstack@rw8.urc.tue.nl (Studenten Vereniging Stack) (05/26/91)
Dump the SCO stuff, get Thomas Roells X386 (X11R4 with everything you ever wanted) and compile Motif1.1.2 yourself with GCC which is rather trivial (It worked for me). Paul Derks paul@stack.urc.tue.nl -- ============================================================================= Email: Internet: rcstack@urc.tue.nl Bitnet: rcstack1@heitue5 Computer Association STACK, Computing Centre RC 1.82, Eindhoven University of Technology, POBox 513, 5600 MB Eindhoven, Holland.
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/28/91)
I don't think one will have much of a compatibility problem running Motif 1.1 with the current (ODT 1.1) SCO or Microfield server. X11R4 added some new "tricks"; if one doesn't use any of the new tricks, R3 servers should do fine. (Sorry, I can't explain *why* I believe this...) P.S.: I shouldn't call a memory leak a "virus". Mole/Pig/Hog perhaps, but not a virus.
campbell@dataco.UUCP (Duncan Campbell) (05/28/91)
Recipe 7. Do not use Motif for real time applications. In fact I have serious misgivings about the use of GUIs in a real time application: they suck cpu cycles and memory like there's nothing else to do and provide very little more than a nice warm fuzzy feeling. Duncan Campbell ***--------------------------------------------------------------*** * DISCLAIMER: * * ==========: * * The opinions expressed are solely of the author and do not * * necessarily reflect the opinions of Canadian Marconi Company. * ***--------------------------------------------------------------***
bturner@hpcvlx.cv.hp.com (Bill Turner) (05/29/91)
>a. create a Label widget; > >b. change the Label widgets string once every few seconds using > XtSetValues; > >c. let it cook for some hours. I'm not sure about SCO's implementation, but the HP Motif 1.0 Label widget (and for that matter any other widget that gets XmStrings as resource values) makes a copy of the XmString ("I can't depend on this value being valid later, I'll make a copy of it so I know it's good."). Are you calling XmStringFree after you XtSetValues of the Label? If not, you should be -- this would cause the leak. XmString tcs; tcs = XmStringCreateLtoR("string for label", XmSTRING_DEFAULT_CHARSET); XtSetArg(args[n], XmNlabel, tcs); n++; XtSetValues(label_widget, args, n); XmStringFree(tcs); --Bill Turner (bturner@hp-pcd.cv.hp.com) HP Interface Technology Operation
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (05/30/91)
In article <645@fudd.dataco.UUCP> campbell@fritz.UUCP (Duncan Campbell, VOR) writes: >Recipe 7. Do not use Motif for real time applications. In fact >I have serious misgivings about the use of GUIs in a real time >application: they suck cpu cycles and memory like there's nothing >else to do and provide very little more than a nice warm fuzzy >feeling. Really? What facts do you base these assertions on? In as much as you can do anything in "real time" on vanilla UNIX, we're doing real time monitoring of the Deep Space Network using Sun 4-330s, MIT X11R4, and Motif 1.1. CPU loads for a typically "loaded" workstation run around the following: average/peak % Xsun: 3 17 display clients: 0 10 user 10 50 These numbers were garnered from the top program during different stages of stress and load testing. There's nothing scientific about how I came up with them; they're seat of the pants numbers. But if 0% of the CPU is "suck(ing) cpu cycles like there's nothing else to do", then I'd like to know what a non-cpu intensive program is? The display clients do peak at 10%, but that's generally when a new display is being created, and there's lots going on. It's easy for any application to be cpu hungry, they don't even have to be GUI based. Our display clients initially used (worse case) 15% cpu at a nominally idle state. A profile run showed that we were beating up the system with excessive system calls. After reengineering our semaphore strategy, cpu usage dropped to an indicated 0%. X11R4/Motif, in our real time application works A-okay. It's fast, it's good looking, and it doesn't core dump. Which would you rather show a Congressman or a visiting foreign dignitary, a bank of 20 year old character based terminals, or state-of-the-art workstations running a GUI? I too have serious misgivings, but it's not about using a GUI on for a mission critical application. It's about the willingness to use vanilla UNIX for a *real* real-time application, considering that there's nothing remotely *real-time* about UNIX. Is it a coincidence that of all the GUIs, only one runs on a *real* real-time operating system? -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov No flashy sig. No clever quips. No famous quotes. This space for rent.
wul@sco.COM (Wu Liu) (06/08/91)
I'm posting this for Scott Deardorff. Please direct any questions or comments about the following to him at scottd@sco.COM... Mr. Wallace and Lamers I'm sorry that you got the impression that we at SCO were not (and by implication, are not) interesting in fixing bugs found in our products. This isn't true; SCO *is* committed to fixing bugs reported by our customers, via new releases, maintainance supplements, and support level supplements (SLS). SLS's are made available via UUCP through a bulletin board maintained by SCO Support; they're also available for anonymous FTP from the SCO hierarchy on UUNET. For more information on how to access this BBS, please contact SCO Customer Service or your SCO Sales representative. We will be making both X11r4 and Motif 1.1 (runtime and development system) available in the next release of Open Desktop, which is expected to ship this fall. Please contact SCO Developer Releations, devrel@sco.COM, if you wish to obtain pre-release versions of the above. As for the problem at hand, how are you using the label widget? The following article, which was posted to comp.windows.x, outlines a possible workaround to your problem: >From: bturner@hpcvlx.cv.hp.com (Bill Turner) >Newsgroups: comp.windows.x >Subject: Re: SCO Motif 1.0 problems (SCO has no plans to fix these) > >>a. create a Label widget; >> >>b. change the Label widgets string once every few seconds using >> XtSetValues; >> >>c. let it cook for some hours. > >I'm not sure about SCO's implementation, but the HP Motif 1.0 Label >widget (and for that matter any other widget that gets XmStrings as >resource values) makes a copy of the XmString ("I can't depend on this >value being valid later, I'll make a copy of it so I know it's good."). > >Are you calling XmStringFree after you XtSetValues of the Label? If >not, you should be -- this would cause the leak. > > XmString tcs; > > tcs = XmStringCreateLtoR("string for label", XmSTRING_DEFAULT_CHARSET); > XtSetArg(args[n], XmNlabel, tcs); n++; > XtSetValues(label_widget, args, n); > XmStringFree(tcs); > >--Bill Turner (bturner@hp-pcd.cv.hp.com) >HP Interface Technology Operation If this does not work around the problem you are experiencing, we would be very interested in receiving some example code demonstrating this, so that we can reproduce your problem in-house and get Engineering to provide a fix. In general, if you discover a bug that can be reproduced with code examples, please send them to SCO Support (support@sco.COM). It allows us to reproduce the problem and gives Engineering a concrete example they can work from. As for the CGI memory leak you mention, the following is an SCO Support Information Tools (IT) script which may address the problem: #### begin IT script #### Using Output Graphics Text causes CGI agent to use up all memory KEYWORDS: ega agent memory output graphics text v_gtext fonts RELEASE: SCO CGI 1.0.1 PROBLEM: If the CGI function Output Graphics Text is called many times (several thousand), the EGA agent process will grow very large in terms of the amount of memory it uses. This can degrade system performance, and cause an unusual amount of disk activity if the agent process must be swapped. CAUSE: A bug in the CGI EGA agent prevents it from properly releasing memory back to the system. SOLUTION: This problem has been corrected in SCO CGI Release 1.1. The problem may be worked around in SCO CGI release 1.0.1 by setting the FONTS environment variable to "/usr/lib/cgi/fonts," or any other directory containing the CGI fonts. If you are using the Bourne shell, the commands to do this are as follows: FONTS=/usr/lib/cgi/fonts export FONTS If the C shell is used, use the following command: setenv FONTS /usr/lib/cgi/fonts #### end IT script #### [ in response to radixii@grebyn.com (Radix II)'s article... ] >From: radixii@grebyn.com (Radix II) >Newsgroups: comp.unix.sysv386,comp.windows.x,comp.windows.x.motif >Subject: SCO Motif 1.0 problems (SCO has no plans to fix these) >Summary: SCO has no plans to use Motif 1.1 or fix 1.0 memory leaks >Keywords: SCO ODT Motif 1.0, memory leaks, serious problems > > BEWARE OF SCO, AND 'LEAKY' ODT, X & MOTIF > > By > > H. J. WALLACE and G. B. LAMERS [ rest of article deleted to save on net bandwidth ]