SCO Motif 1.0 problems (SCO has no plans to fix these)

[Radix II]

                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 at grebyn.com
Oxon Hill Md. USA