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

[Wu Liu]

I'm posting this for Scott Deardorff.  Please direct any questions or
comments about the following to him at scottd at 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 at 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 at 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 at 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 at 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 at grebyn.com (Radix II)'s article... ]
>From: radixii at 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 ]