X11, Xt, Xm and purify
Frode Tenneboe
What I found was quite disturbing. Apart from the tons of
UMRs (Uninitialised Memory Reads), which I understand comes from
dynamic memory allocations, there are also quite a few MLKs
(memory LeaKs) in various parts of X. TMstate.c and TMparse.c
are high on the list. So are functions like XmStringGetNextSegment,
XGetVisualInfo, XmStringInitContext and also possibly XmTextGetString.
And those are the only ones I have found in the short time I have
looked into this. I run Sun Solaris 2.5.1 with BlueStone motif 1.2.4.
Are there logical reasons for this?
Does a leak-free implementation of X/Motif exist for Solaris?
-Frode
--
^ Frode Tennebø | email: f...@edh.ericsson.se ^
| Ericsson Radar AS. N-1788 Halden | |
| Phone: +47 69 21 41 47 | Frode@IRC |
| with Standard.Disclaimer; use Standard.Disclaimer; |
Clive Harris
wrote:
<snip>
>
>Does a leak-free implementation of X/Motif exist for Solaris?
>
> -Frode
>
Frode
This is a very common concern of people who are trying to build
resilient applications based upon X.
I don't know if there are any leak-free implementations, but I work
for a company called Geodesic Systems (www.geodesic.com) whose product
- Great Circle - can absolutely eliminate these leaks in X, and in any
other third party library you may be using - even if you don't have
the source code available. In deployment mode (which is what you'll
need to use to eliminate X leaks) we are a link-time add-in so that by
default, you don't even have to recompile your code, just relink.
Email me (clive....@btinternet.com) if you would like me to send
you some more detailed information.
Regards
Clive Harris
Geodesic Systems.
Chris Nappin
I speak from personal experience of trying to reduce memory leaks in a large X application. Once down to a "small amount" of memory leakage, I had to give up and attribute the fault on our X/Motif libraries.
You will find that newer versions of Motif (e.g. newer than version 1.2) have much less memory leakage. There are several versions of X/Motif that are "memory leak free" but expect to pay for them.
You can of course, using purify, fix the leaks yourself ;-)
ta,
Chris Nappin.
David B. Lewis
|> Are there logical reasons for this?
In the more than 4 years since the release of 1.2.4, lots of these problems
have been fixed, as have similar problems with X11 (but note that Purify
gives off UMRs for code that is not problematic). I suggest that you upgrade.
The latest versions are Motif 2.1.10 and X11R6.4pl3. Those releases also
contain information on how to report problems.
--
David B. Lewis Editor, The Motif Developer: http://www.motifzone.com/tmd/
d...@motifzone.com WebWrangler, The Motif Zone: http://www.motifzone.com/
ken...@nojunk.rahul.net-
Chris Nappin <CNa...@inri.co.uk> wrote:
>Various parts of X, especially Motif, are well known to be very "leaky" in the memory dept!
I disagree. I think recent versions of X and Motif have few leaks and
those leaks are mostly in unusual cases (e.g., custom translation
tables aren't freed if the widget is destroyed).
Most leaks are due to application bugs and can be avoided by careful
programming. My web site has a couple of tutorials on avoiding memory
leaks and other memory corruption problems in X/Motif applications.
--
Ken Lee, http://www.rahul.net/kenton/
T.E.Dickey
> In article <360A59C3...@inri.co.uk>,
> Chris Nappin <CNa...@inri.co.uk> wrote:
>>Various parts of X, especially Motif, are well known to be very "leaky" in the memory dept!
> I disagree. I think recent versions of X and Motif have few leaks and
> those leaks are mostly in unusual cases (e.g., custom translation
> tables aren't freed if the widget is destroyed).
by recent, you must mean (and should specify) Motif 2.x and X11R6.x
(though both have multitudes remaining of references to uninitialized
data, as well as "permanent" leaks). Anyone using Purify learns to
filter that out (unfortunately).
But they're improved somewhat over X11R5 and Motif 1.x (which came out
shortly after Purify hit the street).
> Most leaks are due to application bugs and can be avoided by careful
> programming. My web site has a couple of tutorials on avoiding memory
> leaks and other memory corruption problems in X/Motif applications.
> --
> Ken Lee, http://www.rahul.net/kenton/
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
ken...@nojunk.rahul.net-
T.E.Dickey <dic...@shell.clark.net> wrote:
>> I disagree. I think recent versions of X and Motif have few leaks and
>> those leaks are mostly in unusual cases (e.g., custom translation
>> tables aren't freed if the widget is destroyed).
>by recent, you must mean (and should specify) Motif 2.x and X11R6.x
>(though both have multitudes remaining of references to uninitialized
>data, as well as "permanent" leaks). Anyone using Purify learns to
>filter that out (unfortunately).
I mean Motif 1.2.4 and X11R6.0, both of which have been available for at
least a few years.
UMRs are not bugs and can be safely ignored. Many popular libraries,
including X, use this optimization.
Can you be more specific on the multitudes of serious memory leaks that
you've found? I consider a memory leak to be serious if it happens
more than once in the lifetime of a widget.
T.E.Dickey
> I mean Motif 1.2.4 and X11R6.0, both of which have been available for at
> least a few years.
> UMRs are not bugs and can be safely ignored. Many popular libraries,
> including X, use this optimization.
UMRs are potential sources of core dumps. It says that the program is
copying unintialized data to a new location (unspecified).
> Can you be more specific on the multitudes of serious memory leaks that
> you've found? I consider a memory leak to be serious if it happens
> more than once in the lifetime of a widget.
not at the moment - but the next time I go that way, I'll collect a few.
ken...@nojunk.rahul.net-
T.E.Dickey <dic...@shell.clark.net> wrote:
>In comp.windows.x ken...@nojunk.rahul.net- wrote:
>> UMRs are not bugs and can be safely ignored. Many popular libraries,
>> including X, use this optimization.
>
>UMRs are potential sources of core dumps. It says that the program is
>copying unintialized data to a new location (unspecified).
That is false. The new location is specified properly. Copying
uninitialized data as fine as long as the destination is properly
allocated and not later dereferenced. All UMRs in X and Motif do this
properly. X (and other libraries) does this because a single copy of
an array or struct is faster than multiple copies or unnecessarily
initializing unused fields.
Pedro Proenca
> properly. X (and other libraries) does this because a single copy of
> an array or struct is faster than multiple copies or unnecessarily
> initializing unused fields.
That is non-portable code! The ANSI/ISO C standard does not specify the memory
layout of any data type. Padding and struct aligning can cause problems if you
build your app with different settings. This happens all the time in the
Microsoft Windows world.
Pedro Proenca
-----------------------
pro...@hks.com.NO_SPAM
T.E.Dickey
> In article <6uesm8$ic$1...@clarknet.clark.net>,
> T.E.Dickey <dic...@shell.clark.net> wrote:
>>In comp.windows.x ken...@nojunk.rahul.net- wrote:
>>> UMRs are not bugs and can be safely ignored. Many popular libraries,
>>> including X, use this optimization.
>>
>>UMRs are potential sources of core dumps. It says that the program is
>>copying unintialized data to a new location (unspecified).
> That is false. The new location is specified properly. Copying
> uninitialized data as fine as long as the destination is properly
> allocated and not later dereferenced. All UMRs in X and Motif do this
> properly. X (and other libraries) does this because a single copy of
> an array or struct is faster than multiple copies or unnecessarily
> initializing unused fields.
This will generate a UMR:
#include <stdio.h>
int main()
{
char *x;
char *y = x;
printf("%p\n", y);
return 0;
}
now: what happens if I do this (dumps core for me - after reporting a UMR):
#include <stdio.h>
int main()
{
char *x;
char *y = x;
printf("%s\n", y);
return 0;
}
> --
> Ken Lee, http://www.rahul.net/kenton/
--
Frode Tenneboe
: In article <6uesm8$ic$1...@clarknet.clark.net>,
: T.E.Dickey <dic...@shell.clark.net> wrote:
: >In comp.windows.x ken...@nojunk.rahul.net- wrote:
: >> UMRs are not bugs and can be safely ignored. Many popular libraries,
: >> including X, use this optimization.
: >
: >UMRs are potential sources of core dumps. It says that the program is
: >copying unintialized data to a new location (unspecified).
: That is false. The new location is specified properly. Copying
: uninitialized data as fine as long as the destination is properly
: allocated and not later dereferenced. All UMRs in X and Motif do this
: properly. X (and other libraries) does this because a single copy of
: an array or struct is faster than multiple copies or unnecessarily
: initializing unused fields.
As you can see there is some disagreement. However, I have recived
several replies. The product Great Circle looks promising and I'll
probably look into it. Anyway, Kens reply is favourable for the
latest releases and that is probably a fair assumption.
However, are there particular distributions which should be
avoided? Prevously I have only used BlueStone, IXI and
the one shiped from Sun. My impression is that the BS version
has been better in the memory leak department. Though, I don't know
if this is because it has used a different source base. Any
comments?
David B. Lewis
Or, even better, report the bugs. If you are capable of fixing the leaks,
then you must have source, and if you have source, you purchased it from
The Open Group, and you have a copy of the BUGREPORT file including the
address to send bugs and test-cases to. Other reports can go to the vendor
who provided you with your binary versions of the Motif libraries.
David B. Lewis
|> copying unintialized data to a new location (unspecified).
X calls often use the combination of a structure and a flag mask telling what
fields in the structure to pay attention to. The structure is copied en
masse. I believe Purify throws a UMR here, although the code is written such
that uninitialized fields are not dereferenced unless the flag in the mask
says that there's real data there.
T.E.Dickey
> |> You can of course, using purify, fix the leaks yourself ;-)
> Or, even better, report the bugs. If you are capable of fixing the leaks,
> then you must have source, and if you have source, you purchased it from
> The Open Group, and you have a copy of the BUGREPORT file including the
for Motif, of course.
(iirc, though, the Xt bundled with Motif was made incompatible with
the MIT sources to solve a shared-library quibble)
T.E.Dickey
> |> UMRs are potential sources of core dumps. It says that the program is
> |> copying unintialized data to a new location (unspecified).
> X calls often use the combination of a structure and a flag mask telling what
> fields in the structure to pay attention to. The structure is copied en
> masse. I believe Purify throws a UMR here, although the code is written such
> that uninitialized fields are not dereferenced unless the flag in the mask
> says that there's real data there.
maybe - but I'll have to assume that unless someone can automatically
verify that all of the UMRs are harmless, there's some bugs.
(Purify's more likely correct than whoever signed off on this ;-)
Nhi Vanye
Purify is just a tool, you need to understand both the code its analysing
and how it works.
I've seen too many bogus errors from it to take what it says as gospel.
Its good, but its no subsitute for knowing the code.
>Thomas E. Dickey
richard.
--
Richard M. Offer Widget FAQ --> http://reality.sgi.com/widgetFAQ
MTS-Core Design (Motif)
___________________________________________http://reality.sgi.com/offer
Michael Morrell
> |> UMRs are potential sources of core dumps. It says that the program is
> |> copying unintialized data to a new location (unspecified).
> X calls often use the combination of a structure and a flag mask telling what
> fields in the structure to pay attention to. The structure is copied en
> masse. I believe Purify throws a UMR here, although the code is written such
> that uninitialized fields are not dereferenced unless the flag in the mask
> says that there's real data there.
I believe that the above is considered a UMC (uninitialized memory copy),
not a UMR. UMCs are not bugs, but UMRs are. Purify attempts to distinguish
the two. One area where it fails is passing a struct pointer to a function.
If any of the fields in the structure are uninitialized, this is treated as
an UMR instead of the UMC it should be treated as.
Michael
ken...@nojunk.rahul.net-
Michael Morrell <mor...@cup.hp.com> wrote:
>> X calls often use the combination of a structure and a flag mask telling what
>> fields in the structure to pay attention to. The structure is copied en
>> masse. I believe Purify throws a UMR here, although the code is written such
>> that uninitialized fields are not dereferenced unless the flag in the mask
>> says that there's real data there.
>
>I believe that the above is considered a UMC (uninitialized memory copy),
>not a UMR.
Maybe I was using an older version of Purify, but last time I used it
the above was a UMR. I agree that this is safe to do.
Cameron Hayne
<dic...@shell.clark.net> wrote:
>maybe - but I'll have to assume that unless someone can automatically
>verify that all of the UMRs are harmless, there's some bugs.
>(Purify's more likely correct than whoever signed off on this ;-)
It's not an issue of which piece of software is more correct. As others
have tried to explain, it is merely a fact that Purify does not (cannot)
know that the memory copying is okay since Purify does not (cannot) understand
the code.
There may be bugs - that is always true - but a Purify message is not
necessarily evidence of a bug. Instead it is an indication that the
corresponding code should be examined to check if it might be a bug.
--
Cameron Hayne (ha...@crim.ca)
Centre de recherche informatique de Montreal
Glenn Pinkerton
: It's not an issue of which piece of software is more correct. As others
: have tried to explain, it is merely a fact that Purify does not (cannot)
: know that the memory copying is okay since Purify does not (cannot) understand
: the code.
: There may be bugs - that is always true - but a Purify message is not
: necessarily evidence of a bug. Instead it is an indication that the
: corresponding code should be examined to check if it might be a bug.
I think the problem is one of how we mere mortal humans can effectively
filter out the small number of valid messages from the plethora of unimportant
messages reported from any third party library. It's very much like turning
on the higest warning level in a compiler. Only a very few of the warnings
are meaningful, but you pretty much have to fix all of them to be able to
find the meaningful messages in the mess. I personally think that the
optimizations spoken of which cause the plethora of UMR's are not very important
from an overall throughput of the application perspective. I will almost always
opt for code that compiles and runs through a memory checker cleanly over any
optimizations that add significant numbers of warning messages.
All software will eventually break. The best we can do is give ourselves a
sporting chance to fix it when it breaks. I think eliminating large numbers of
UMR's in a library give people a more sporting chance to fix their software.
Glenn Pinkerton
g...@csn.org
Kevin W. Ramer
> In article <6uef57$f5e$2...@clarknet.clark.net>,
> T.E.Dickey <dic...@shell.clark.net> wrote:
>
> UMRs are not bugs and can be safely ignored. Many popular libraries,
> including X, use this optimization.
I entered this thread late and am looking through this discussion.
I strongly disagree with the above statement. I have been consulting at
a large telecommunications firm for the past three years. About a year
ago a problem came about where that company's customers were receiving
whopping credit (hundreds of thousands $) on their bills when adjustments were
being applied to them. I traced this to a UMR on a local double variable
that was
being used in a calculation.
>
> Can you be more specific on the multitudes of serious memory leaks that
> you've found? I consider a memory leak to be serious if it happens
> more than once in the lifetime of a widget.
Second example. Just these last two weeks our new Sun machines were
upgraded to 2.6 of Solaris. I was running purify and found that it was raining.
This and other subsequent problems caused quite a stir in Sun (yesterday a guy
appeared with source for all their current patch levels) as we are
attempting to put a pilot Sun installation 10-8. Fortunately, we discovered
that the installation of the upgrade introduced the problems.
> --
--
Kevin W. Ramer ram...@earthlink.net
Programmer-at-Large
If pro is the opposite of con then Congress must be the opposite
of Progress -- Gallagher
T.E.Dickey
> I think the problem is one of how we mere mortal humans can effectively
> filter out the small number of valid messages from the plethora of unimportant
> messages reported from any third party library. It's very much like turning
> on the higest warning level in a compiler. Only a very few of the warnings
> are meaningful, but you pretty much have to fix all of them to be able to
> find the meaningful messages in the mess. I personally think that the
> optimizations spoken of which cause the plethora of UMR's are not very important
> from an overall throughput of the application perspective. I will almost always
> opt for code that compiles and runs through a memory checker cleanly over any
> optimizations that add significant numbers of warning messages.
exactly (there's two ways to respond to it: one fixes the problem and the
other says the messages don't mean anything). We used to say that about lint.
(Even if only 10% of the messages mean something, that's worth doing).
-- I still use lint too.
ken...@nojunk.rahul.net-
> I think the problem is one of how we mere mortal humans can effectively
> filter out the small number of valid messages from the plethora of unimportant
> messages reported from any third party library.
Purify has a suppress command. You can use it to suppress UMRs in the
X (and other) libraries without affecting UMR reports from your application
code.
Glenn Pinkerton
Of course you can suppress various messages for various libraries. However,
one can never be certain if any of the messages suppressed in the library are
actually caused by improper usage of the library from your own code.
It really isn't that much effort to fix these problems. When I first started
using memory checking tools on my software, which has several hundred thousand
lines of code, I probably had over 1000 "unimportant" messages reported. I
fixed them all on a piece by piece basis when not being particularly active
with other things. I did find several real problems during this process, which
took about 2 months.
As far as the performance is concerned, I stick by my philosophy that the
performance gained by avoiding a memset (e.g. using calloc instead of malloc),
which is usually the fix for a UMR, is insignificant relative to good algorithm
development and relative to the speed of modern computers.
Glenn Pinkerton
g...@csn.org
David B. Lewis
|> necessarily evidence of a bug. Instead it is an indication that the
|> corresponding code should be examined to check if it might be a bug.
Exactly.
It is somewhat ironic that Purify is so good a tool that its output is
automatically trusted, as are the results from AcquaProva, a similar (and
much cheaper!) tool by CenterLine. These tools are a great help, but what
they report shouldn't be taken as Gospel. Rational distributes suppression
files for use with various versions of Xlib, Xt, and Motif.
David B. Lewis
|> that was being used in a calculation.
Ah, but that's a UMR that shouldn't be ignored. Purify is a win here.
T.E.Dickey
> |> There may be bugs - that is always true - but a Purify message is not
> |> necessarily evidence of a bug. Instead it is an indication that the
> |> corresponding code should be examined to check if it might be a bug.
> It is somewhat ironic that Purify is so good a tool that its output is
> automatically trusted, as are the results from AcquaProva, a similar (and
> much cheaper!) tool by CenterLine. These tools are a great help, but what
> they report shouldn't be taken as Gospel. Rational distributes suppression
> files for use with various versions of Xlib, Xt, and Motif.
Even better would be to fix the problems in Xlib, etc., rather than to assert
that Purify is incorrect (or should be taken with a grain of salt).
David B. Lewis
|> the MIT sources to solve a shared-library quibble)
You mean way back in Motif 1.0, which became obsolete in 1991?
Motif is now at 2.1.10, using X11R6.
David B. Lewis
He is referring to a structure copy.
Incidentally, I just tried using Purify to generate some UMRs for code that
does this. The tool appears not to do so, at least in version 4.2, for code
compiled with -g.
--
David B. Lewis At but not speaking for ICS (Cambridge, MA)
dbl AT ics.com
bob schulman
> Even better would be to fix the problems in Xlib, etc., rather than to assert
> that Purify is incorrect (or should be taken with a grain of salt).
Not necessarily. I've seen plenty of reports from Purify of what appear to
be egregious errors. Gee whiz...change -O to -g in the compile line, recompile,
and the problems disappear. So, um, is the problem in the code or the
code generator?
The problem's obviously in the code generator. One could go complain
to Cygnus or the folks at FSF (the code generator twas gcc), or one
could just get on with one's job.
In all my time Purify'ing Motif 2.0 and X11R6 the vast vast vast majority
of problems fall into the lap of aggresive optimizations of gcc rather
than the fault of the X Consortium or The Open Software Foundation.
bob
T.E.Dickey
> In comp.windows.x T.E.Dickey <dic...@shell.clark.net> wrote:
>> Even better would be to fix the problems in Xlib, etc., rather than to assert
>> that Purify is incorrect (or should be taken with a grain of salt).
> In all my time Purify'ing Motif 2.0 and X11R6 the vast vast vast majority
> of problems fall into the lap of aggresive optimizations of gcc rather
> than the fault of the X Consortium or The Open Software Foundation.
That doesn't seem to be how you viewed it before. Here's a quote courtesy
of DejaNews:
re: vxworks 5.2 and X memory leak. more options
Author: bob schulman
Email: b...@seaweed.com
Date: 1997/03/13
Forums: comp.os.vxworks
more headers
_________________________________________________________________
> I have no experience with a similar VxWorks configuration but having worked
> with X for a while, I know that it has a reputation for having a significant
> number of latent memory leaks. Virtually of the X windows systems I've used
> force you to kill X after a period of time to prevent you from exhausting you
r
> virtual memory. I don't think there is a fix for the MIT distribution; there
> may be some private distributions which have fixed them but if so, I am unawa
re
> of them.
Whoa! Not true at all. Seaweed's SeaWind product (X11R6+Motif 2.0 for
VxWorks) has been compiled up and run under the Purify environment
and Purify has almost no memory leak complaints (well, there are a couple
in the Drag 'n' Drop and a badly engineered free routine for a special
data structure in Motif). But the Xlib/Xt/(grand majority of)Motif 2.0
code is clean clean clean. So if there is a "reputation for having a
significant number of latent memory leaks", I'd have to say that such
a reputation is ill-deserved and probably based on old releases of X
or Motif.
By the way, Purify was implemented by a gentlemen who used to be a
Motif consultant who was so sick and tired of memory leaks,
array over/underruns, and references to uninitialized memory in
the code from OSF that he went and invented Purify. Pure Software turned out
to be much more lucrative than Motif consulting. So, Motif used to
be a pretty sick puppy, but those days are long gone.
bob
> bob
bob schulman
> > In all my time Purify'ing Motif 2.0 and X11R6 the vast vast vast majority
> > of problems fall into the lap of aggresive optimizations of gcc rather
> > than the fault of the X Consortium or The Open Software Foundation.
And then T.E.Dickey did some excavating:
> That doesn't seem to be how you viewed it before. Here's a quote courtesy
> of DejaNews:
Because I said earlier:
> Whoa! Not true at all. Seaweed's SeaWind product (X11R6+Motif 2.0 for
> VxWorks) has been compiled up and run under the Purify environment
> and Purify has almost no memory leak complaints (well, there are a couple
> in the Drag 'n' Drop and a badly engineered free routine for a special
> data structure in Motif). But the Xlib/Xt/(grand majority of)Motif 2.0
> code is clean clean clean. So if there is a "reputation for having a
> significant number of latent memory leaks", I'd have to say that such
> a reputation is ill-deserved and probably based on old releases of X
> or Motif.
Yeah, so? The key in the older quote is "a reputation [of being leak-ridden]
is ill-deserved and probably based on old releases of X or Motif." The key
in the first quote had to do with number of reports by Purify. The vast
majority of such reports are still caused by aggresive optimizations
by gcc.
When I created the older posting, I had already deprecated reports from
Purify about the gcc optimizations. Like Kenton Lee, I believe there are some
reports from Purify that don't make any Real Sense and should just
be ignored. So I ignored them.
Given that, what's your point?
bob
Pedro Proenca
>
> I recently said:
> > > In all my time Purify'ing Motif 2.0 and X11R6 the vast vast vast majority
> > > of problems fall into the lap of aggresive optimizations of gcc rather
> > > than the fault of the X Consortium or The Open Software Foundation.
I just would like to remind you that most UNIX vendors still use Motif 1.x,
which is not so "pure". Motif 2.0 is not widely available (<RELIGIOUS WAR> why
bother if we have Win32 anyway? </RELIGIOUS WAR>)
Pedro Proenca
---------------
pro...@hks.com.NO_SPAM
bob schulman
> I just would like to remind you that most UNIX vendors still use Motif 1.x,
> which is not so "pure". Motif 2.0 is not widely available (<RELIGIOUS WAR> why
> bother if we have Win32 anyway? </RELIGIOUS WAR>)
Yes, well, there is that. (<Silly Mode> As far religious wars go, do you know
of any Win32 interfaces available for Unix boxes? And if you do, do you know
how that interface fares under Purify? </Silly Mode>)
bob
kskei...@my-dejanews.com
> Even better would be to fix the problems in Xlib, etc.,
What problems? Did you ever file bug-reports against Xlib? I suspect not (and
can no longer check) but last time I looked the number of open bug-reports for
memory-type errors was near zero.
> rather than to assert
> that Purify is incorrect (or should be taken with a grain of salt).
Ahem, I assert that Purify is often incorrect. I base that assertion on the
fact that I have run Purify on Xlib (and the rest of the sample
implementation) and analyzed the sources where Purify reports problems and
found no problem.
When real problems were found, they were fixed. I call your attention to this
paragraph in the release notes for X11R6.4:
Beginning circa X11R5 the MIT X Consortium staff, and later the X Con-
sortium, Inc. staff, and now the X Project Team staff have routinely
tested this implementation for a variety of memory-type errors such as
leaks, array bounds writes, uninitialized memory reads, and a variety of
other errors; using a combination of commercial and "home grown" memory
testing tools. All the real problems were fixed long ago; however we
aren't so naive as to believe that there no remaining bugs. If you find
a memory problem in this implementation please file a bug-report. If you
find a memory problem in your vendor's implementation, tell your vendor.
The popular commercial memory checking tools emit lots of false or spu-
rious warnings, most of which can be safely ignored.
So, if you know of a bug in the sample implementation that has thus far
escaped detection, I recommend that you file a bug-report, i.e. get a copy of
the bug-report template from the release, fill it out, and email it to
xb...@x.org, and I'm sure it will receive prompt attention.
--
Kaleb S. KEITHLEY
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
David B. Lewis
Complain to them! There's really no reason that you should put up with
software several *years* out of date.
dav...@crl.com
With the version I had way back in the bad'ol'days
(somethin' like Motif 1.1.x...?) there were lots of
leaks and UMRs and whatnot that Purify reported.
I was investigating some buggy behavior and saw these
reports and went and fixed the UMR's in the Motif source.
(There was one or two cases I found where clearly
they malloc()'d some memory then didn't initialize it).
Simply adding a memset(...0...) cured the buggy
behavior and made the application apparently faster
to boot.
Now ... this was with way old version of Motif
about 6 yrs ago. They've surely done the same
things themselves ...? Haven't they?
David
In comp.windows.x ken...@nojunk.rahul.net- wrote:
: In article <360A59C3...@inri.co.uk>,
: Chris Nappin <CNa...@inri.co.uk> wrote:
: >Various parts of X, especially Motif, are well known to be very "leaky" in the memory dept!
: I disagree. I think recent versions of X and Motif have few leaks and
: those leaks are mostly in unusual cases (e.g., custom translation
: tables aren't freed if the widget is destroyed).
: Most leaks are due to application bugs and can be avoided by careful
: programming. My web site has a couple of tutorials on avoiding memory
: leaks and other memory corruption problems in X/Motif applications.
: --
: Ken Lee, http://www.rahul.net/kenton/
--
Web site creation and hosting assistance available for spiritual
healers and teachers. See http://7gen.com for more info
dav...@crl.com
UMR is most certainly a potential bug. It all depends
on what is done with the randam garbage that is copied
from the uninitialized piece of memory.
That is ... for UMR to happen you have
- A read operation happening on a piece of memory
- Purify believes that this memory has not been
initialized yet
- Assume for the rest that Purify is correct
- Uninitialized memory has random garbage in it
- This random garbage is being used in some calculation
or other operation
- Therefore the operation being performed will end
up with wrong result because it is based in part
on random garbage
The wrong result will vary from benign (if the garbage
value is within the range of acceptible values for
that operation) up to horrible (if outside the range
of acceptible values).
For instance ... if the memory allocated used to be
part of a character string and you're interpreting
it now as a struct with pointers in it. If you
try to dereference one of the pointers you'll likely
get a core dump because it's an invalid address.
I don't know how you can claim UMR is not a bug ...
David
In comp.windows.x ken...@nojunk.rahul.net- wrote:
: In article <6uesm8$ic$1...@clarknet.clark.net>,
: T.E.Dickey <dic...@shell.clark.net> wrote:
: >In comp.windows.x ken...@nojunk.rahul.net- wrote:
: >> UMRs are not bugs and can be safely ignored. Many popular libraries,
: >> including X, use this optimization.
: >
: >UMRs are potential sources of core dumps. It says that the program is
: >copying unintialized data to a new location (unspecified).
: That is false. The new location is specified properly. Copying
: uninitialized data as fine as long as the destination is properly
: allocated and not later dereferenced. All UMRs in X and Motif do this
: properly. X (and other libraries) does this because a single copy of
: an array or struct is faster than multiple copies or unnecessarily
: initializing unused fields.
Nhi Vanye
A general UMR can be a bug, the ones in question aren't. Multiple people
have gone over the code with a fine toothed comb, and what purify (in
these cases) reports is bogus.
Whether you then extrapolate this information to say all UMRs are bogus
is upto you.
Purify is a tool, to be of any real use you need to know what its
limitations are *and know* the code you're working on.
If you don't belive they people that say its not a bug, there's not
a lot you can do except buy the source code and check for yourself
(assuming the source is available).
> David
Douglas Ridgway
>In comp.windows.x Pedro Proenca <pro...@hks.com> wrote:
>> bother if we have Win32 anyway? </RELIGIOUS WAR>)
>
>Yes, well, there is that. (<Silly Mode> As far religious wars go, do you know
>of any Win32 interfaces available for Unix boxes? And if you do, do you know
>how that interface fares under Purify? </Silly Mode>)
There are several, I'm most familiar with Wine (http://www.winehq.com/).
I'd be quite interested in hearing about Purify results for Wine
or a Wine-ported application.
Pedro Proenca
>
> On 29 Sep 1998 23:35:22 GMT, bob schulman <b...@seaweed.com> wrote:
> >In comp.windows.x Pedro Proenca <pro...@hks.com> wrote:
> >> I just would like to remind you that most UNIX vendors still use Motif 1.x,
> >> which is not so "pure". Motif 2.0 is not widely available (<RELIGIOUS WAR> why
> >> bother if we have Win32 anyway? </RELIGIOUS WAR>)
> >
> >Yes, well, there is that. (<Silly Mode> As far religious wars go, do you know
> >of any Win32 interfaces available for Unix boxes? And if you do, do you know
> >how that interface fares under Purify? </Silly Mode>)
>
Actually I know of at least 3: one from Mainsoft (used by MS for the UNIX
ports of IE 4), one from Bristol Technologies, and one from Willows. As far as
being "pure" I don't know. But since NuMega's Bounds Checker is much better
than Purify, I'd say that they must be in pretty good shape :-)
But it seems you missed my point: Win32 is a much better API than Motif :-)
Pedro Proenca
---------------
pro...@hks.com
Joe Laughlin
Because you didn't read Ken's response. The X structures are full of pad
fields for alignment reasons. These pad fields are *NEVER* used. Why
spend time initializing fields that are *NEVER* used? Purify will still
complain about the unititialized and unused pad fields when the structures
are copied, because it can't know that those fields are *NEVER* used. Now
do you get it?
===================================================================
Joe Laughlin | E-Mail: jlau...@wpine.com
Sr. Development Engineer | Phone: (603) 886-0903 x 318
White Pine Software | Fax: (603) 886-9051
542 Amherst St. |
Nashua NH, 03063 |
T.E.Dickey
> A general UMR can be a bug, the ones in question aren't. Multiple people
> have gone over the code with a fine toothed comb, and what purify (in
> these cases) reports is bogus.
multiple people have asserted that the code is fine. but that's only an
assertion. there's multiple paths through the X windows library (I suppose
next we'll hear from someone claiming that they've done 100% test coverage,
except of course for the code that isn't really used anyway ;-)
> If you don't belive they people that say its not a bug, there's not
> a lot you can do except buy the source code and check for yourself
> (assuming the source is available).
I'm aware of several memory-issue bugs in the X Window system fixed since
X11R6. (I found some of them using Purify ;-)
T.E.Dickey
> It's been many years since I programmed with Motif.
> With the version I had way back in the bad'ol'days
> (somethin' like Motif 1.1.x...?) there were lots of
> leaks and UMRs and whatnot that Purify reported.
> I was investigating some buggy behavior and saw these
> reports and went and fixed the UMR's in the Motif source.
> (There was one or two cases I found where clearly
> they malloc()'d some memory then didn't initialize it).
> Simply adding a memset(...0...) cured the buggy
> behavior and made the application apparently faster
> to boot.
> Now ... this was with way old version of Motif
> about 6 yrs ago. They've surely done the same
> things themselves ...? Haven't they?
apparently not.
the preferred method seems to be to declare them not really bugs.
> David
T.E.Dickey
>>I don't know how you can claim UMR is not a bug ...
> Because you didn't read Ken's response. The X structures are full of pad
> fields for alignment reasons. These pad fields are *NEVER* used. Why
> spend time initializing fields that are *NEVER* used? Purify will still
> complain about the unititialized and unused pad fields when the structures
> are copied, because it can't know that those fields are *NEVER* used. Now
> do you get it?
I 'got' it a long time ago: using calloc doesn't cost much more than malloc,
makes testing reproducible - and years later when Purify came out, it didn't
have anything to complain about.
kskei...@my-dejanews.com
"T.E.Dickey" <dic...@shell.clark.net> wrote:
> In comp.windows.x.motif Nhi Vanye <of...@sgi.com> wrote:
> > A general UMR can be a bug, the ones in question aren't. Multiple people
> > have gone over the code with a fine toothed comb, and what purify (in
> > these cases) reports is bogus.
>
> multiple people have asserted that the code is fine. but that's only an
> assertion.
You assert it's not fine. And even that is only an assertion.
What do you want to do, get together and slug it out with baseball bats?
> there's multiple paths through the X windows library
And pad bytes are still pad bytes, no matter what path you take through the
library.
> (I suppose
> next we'll hear from someone claiming that they've done 100% test coverage,
Is someone hoarding a test that covers 100% of the X sources?
> except of course for the code that isn't really used anyway ;-)
What code isn't used?
> I'm aware of several memory-issue bugs in the X Window system fixed since
> X11R6. (I found some of them using Purify ;-)
Did you file bug-reports? People who filed bug-reports and provided test
cases got their bugs fixed. People who filed bug-reports and didn't provide
test cases also probably got their bugs fixed. People who don't file
bug-reports didn't get their bugs fixed. Meet me half way Mendel, buy a
lottery ticket.
--
Kaleb S. KEITHLEY
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
T.E.Dickey
> What do you want to do, get together and slug it out with baseball bats?
that seems to be your usual approach to people discussing things
(but since no one on this group seems to know much about testing, that's
what we're reduced to).
good luck with your customers.
> Is someone hoarding a test that covers 100% of the X sources?
>> except of course for the code that isn't really used anyway ;-)
> What code isn't used?
The ";-)" is indicating irony - lost here.
>> I'm aware of several memory-issue bugs in the X Window system fixed since
>> X11R6. (I found some of them using Purify ;-)
> Did you file bug-reports? People who filed bug-reports and provided test
I didn't need to - the ones I found myself went into fixes for XFree86.
(not all were xterm fixes - though you did comment that TOG had no interest
in fixing that unless someone came up with more money)
Cameron Hayne
<dic...@shell.clark.net> wrote:
>In comp.windows.x.motif kskei...@my-dejanews.com wrote:
>> What do you want to do, get together and slug it out with baseball bats?
>
>that seems to be your usual approach to people discussing things
This is way out of line. I have seen no evidence whatsoever that
Kaleb (or indeed anyone else in this newsgroup) is averse to discussions
of relevant issues.
(but since no one on this group seems to know much about testing, that's
what we're reduced to).
Again, where is your evidence for this lack of knowledge ?
You seem upset that people want to see more evidence than merely
a Purify UMR message before they will consider that the X, Xt, or
Motif code is buggy. Yes, it would be nice if all the code in the
world passed through validity checkers (like Purify) without any
warning messages, but there are other factors (tradeoffs) that make
this unlikely for the foreseeable future.
And in particular, messages warning about uninitialized parts of
C structures are analogous to a computerized house warning you
that you forgot to take your driver's licence when you go out for
a walk. A useful warning in some circumstances, but one that
you can justifiably ignore when you know that you won't need the licence.
--
Cameron Hayne (ha...@crim.ca)
Centre de recherche informatique de Montreal
Glenn Pinkerton
: You seem upset that people want to see more evidence than merely
: a Purify UMR message before they will consider that the X, Xt, or
: Motif code is buggy. Yes, it would be nice if all the code in the
: world passed through validity checkers (like Purify) without any
: warning messages, but there are other factors (tradeoffs) that make
: this unlikely for the foreseeable future.
: And in particular, messages warning about uninitialized parts of
: C structures are analogous to a computerized house warning you
: that you forgot to take your driver's licence when you go out for
: a walk. A useful warning in some circumstances, but one that
: you can justifiably ignore when you know that you won't need the licence.
I don't think the issue is whether any particular third party library
is buggy. The issue is that a lot of messages from the third party
library reduces the usefulness of the memory checking tool. I know
that these messages can be suppressed, but I contend that one never really
knows if the suppressed message was caused by the application interfacing
improperly with the library or caused internally in the library.
I think that the high quality solution would be to make your libraries
as clean as possible. If you are trying to sell a product for other
developers use, then making their lives easier is just good business
sense.
A point has been made that fixing some of these messages can hurt
performance. I think this is a minor issue at best. In today's hardware
world, slightly inefficient coding is not particularly important. Good
algorithm development seems to almost always be the deciding performance
factor.
Glenn Pinkerton
g...@csn.org
T.E.Dickey
> A point has been made that fixing some of these messages can hurt
> performance. I think this is a minor issue at best. In today's hardware
> world, slightly inefficient coding is not particularly important. Good
> algorithm development seems to almost always be the deciding performance
> factor.
the X library source to switch to the 'slightly inefficient' style for
testing (and validation) purposes.
(That would be done, of course, by substituting calloc for malloc at the
low level - but there's no evidence in the code that it's been done, and
the people saying that someone 'looked' at the code don't seem to understand
the technical issue -- perhaps eventually we'll hear from someone who's
actually _done_ the testing).
> Glenn Pinkerton
> g...@csn.org
kskei...@my-dejanews.com
"T.E.Dickey" <dic...@shell.clark.net> wrote:
> In comp.windows.x.motif kskei...@my-dejanews.com wrote:
>
> > What do you want to do, get together and slug it out with baseball bats?
>
> that seems to be your usual approach to people discussing things
A personal attack? Has Theo been coaching you?
You've shown your true colors. I have nothing further to say to you now
either.
Cameron Hayne
> The issue is that a lot of messages from the third party
>library reduces the usefulness of the memory checking tool. I know
>that these messages can be suppressed, but I contend that one never really
>knows if the suppressed message was caused by the application interfacing
>improperly with the library or caused internally in the library.
In the case of UMR messages being discussed, this cannot be the fault
of the code that calls the library functions. In general, except for
the case of messages about memory leaks (as opposed to incorrect use
of memory) Purify messages cannot be due to improper use of a library.
> I think that the high quality solution would be to make your libraries
>as clean as possible. If you are trying to sell a product for other
>developers use, then making their lives easier is just good business
>sense.
> A point has been made that fixing some of these messages can hurt
>performance. I think this is a minor issue at best.
I think everyone will agree that in an ideal world, the libraries
would not be targetted by Purify messages. But the issue is not merely
one of performance. There is no free lunch. Making any change, no matter
how trivial, in software does require time be spent on validating and
testing that the change is correct. This time could instead be spent on
other things - there are always more bugs to fix.
Cameron Hayne
<dic...@shell.clark.net> wrote:
>(That would be done, of course, by substituting calloc for malloc at the
>low level - but there's no evidence in the code that it's been done, and
>the people saying that someone 'looked' at the code don't seem to understand
>the technical issue -- perhaps eventually we'll hear from someone who's
>actually _done_ the testing).
If your baby cries in the night, you go and "look" to see if there is
a problem. Just because it cries is no reason to rush it to the hospital.
Babies are known to cry for reasons that do not require medical care.
Purify messages are known to be sometimes wrong.
T.E.Dickey
>> that seems to be your usual approach to people discussing things
> A personal attack? Has Theo been coaching you?
No. Theo and you are too much alike for me to want to emulate either.
(I could quote from your earlier email, showing the similarities, but
that would be a waste of my time).
> You've shown your true colors. I have nothing further to say to you now
> either.
(hope you stick to it, but that's a little too much to ask)
David B. Lewis
|> low level - but there's no evidence in the code that it's been done, and
Now that we're not letting this horse die, let me comment on this suggestion
that calloc is better than malloc for "validation" purposes.
I suggest that having memory automatically initialized to 0, and later used
when it is not intended to be, is more dangerous than in the unvalidated
version, when invalid values such as 0xdeadbeef or the 0xa5a5a5a5 (which I
think is what CodeCenter uses for uninitialized memory) are likely to later
show up as invalid and as errors.
Wiping memory clean and assuming that 0 values are OK is bogus. They are not
necessarily any better than random garbage values.
In any case, "validation" systems have a concept of "known failures" that, in
part, recognize their own limitations and the "observer effect" involved in
using such tools. For example, CodeCenter occasionally reports uninitialized
memory right in the middle of a chunk of data describing an X11 bitmap, when
its pattern for uninitialized memory happens to appear.
kskei...@my-dejanews.com
>(That would be done, of course, by substituting calloc for malloc at the
>low level - but there's no evidence in the code that it's been done,
Another unsubstantiatable assertion. It doesn't take a rocket scientist to go
into Xlibint.h and change the '#define Xmalloc(size) malloc(size)' to '#define
Xmalloc(size) calloc(size,1)' or '#define Xmalloc(size)
mymalloc-that-initializes-memory-to-0xdeadbeef(size)` and rebuild the library
and test with it.
If you want proof that that was done, I'd say you're asking an awful lot of
something you got for free. The release notes for X11R6.4, where it says that
the libraries are routinely tested for memory problems is probably all the
proof you're likely to get.
>and
>the people saying that someone 'looked' at the code don't seem to understand
>the technical issue
What makes you say that? Or are we all just supposed to say, "oh, it's you
T.E.", and take your word for it?
> -- perhaps eventually we'll hear from someone who's
>actually _done_ the testing).
You have, but you'd rather make personal attacks than have a rational debate
on the technical issues.
kskei...@my-dejanews.com
"T.E.Dickey" <dic...@shell.clark.net> wrote:
> In comp.windows.x kskei...@my-dejanews.com wrote:
> > T.E. Dickey wrote:
> >> that seems to be your usual approach to people discussing things
>
> > A personal attack? Has Theo been coaching you?
>
> No. Theo and you are too much alike for me to want to emulate either.
> (I could quote from your earlier email, showing the similarities, but
> that would be a waste of my time).
Another personal attack?!? I guess this means you don't have any sort of a
technical rebuttal to the quasi-technical question I posed, right? Can you not
stick to the technical debate without resorting to personal attacks?
So really, what do you have to support your assertion that the UMRs caused by
the pad bytes is a real problem.
> > You've shown your true colors. I have nothing further to say to you now
> > either.
>
> (hope you stick to it, but that's a little too much to ask)
When you make it a challenge like that, what do you expect?
I'd like to see you stick to the technical debate without resorting to the
personal attacks, but that too seems a little too much to ask.
If you want to see a "test" Xlib that callocs all the memory instead of
mallocing it, why don't you go ahead and do it, if it's so important to you.
Why you'd demand to see that in free software is beyond me.
Moreover, the fact that you'd take the free software, find bugs, fix them,
but go out of your way to not give the fixes back seems mighty strange to me.
Mighty strange.
T.E.Dickey
> I'd like to see you stick to the technical debate without resorting to the
> personal attacks, but that too seems a little too much to ask.
most of your email is abusive - what's new about that?
I'm sure you get a lot of fan mail that fans the flames.
> If you want to see a "test" Xlib that callocs all the memory instead of
> mallocing it, why don't you go ahead and do it, if it's so important to you.
> Why you'd demand to see that in free software is beyond me.
I didn't say that: find/quote me, but don't make up things.
(use some facts).
> Moreover, the fact that you'd take the free software, find bugs, fix them,
> but go out of your way to not give the fixes back seems mighty strange to me.
> Mighty strange.
duh: you've told the world more than once that you aren't interested in
the fixes.
Jim Gettys
Please, all, STOP this useless thread....
For better, or for worse (probably for the worse), there are X interfaces
that make it difficult to do checking of uninitialized memory references.
In fact, they cannot be checked unless checked across library
boundaries, and with DYNAMIC analysis of the execution, not static
analysis.
Let's take an example of XChangeGC:
To remind you, the interface is:
XChangeGC(Display *display,GC gc,unsigned long valuemask, XGCValues *values)
This allows for relatively compact to write and very fast C idioms, where
for example, you can do things like:
{
XGCValues values;
values.foreground = red;
values.background = blue;
XChangeGC(display, gc, GCForeground|GCBackground, &values);
}
to set both foreground and background colors. (pardon me if I get something
slightly wrong; it has been a LONG time; I actually had to go read my
own book to refresh my cache).
XChangeGC is written such that it will only access members of the values
structure that have been specified by the valuemask argument.
Now, unless you have a tool which can divine that both the caller and
the callee have actually set/accessed the values specified in the valuemask,
which would require full dynamic code analysis to do, you aren't going
to know if uninitialized memory was referenced.
So, guess what, a conservative tool that doesn't track the execution
of every instruction complains about an uninitialzed value though all
values ACTUALLY used by XChangeGC have all been initialized.
So you get spurious complaints out of tools,
which require actual thought to determine that they can be safely ignored.
This is unfortunate, but this is reality.
To get such to shut up, I suppose you could initialize the values structure.
But you are programming in C, after all.
This is called the C programming language, folks.
There are better languages out there, I recommend them to your attention.
Now, if I were desiging these interfaces again, today, I might choose
a different interface just to help out tools like purify, (or atom, and
all the other goodies that exist 10 years after I designed them), just
to keep them quiet; but then again, I'd be using a different language
in the first place, and I have more experience than I did over 10 years
ago. At the time, ansii C wasn't even available, and the best you could
do was lint with old style procedure signatures (and lint was broken
on most platforms of the day).
So enough already, of a useless thread, unless you find actual bugs; at
which I hope you'll fix them and report them in the right direction(s).
End of flame,
- Jim Gettys
kskei...@my-dejanews.com
"T.E.Dickey" <dic...@shell.clark.net> wrote:
> In comp.windows.x.motif kskei...@my-dejanews.com wrote:
> > I'd like to see you stick to the technical debate without resorting to the
> > personal attacks, but that too seems a little too much to ask.
>
> most of your email is abusive - what's new about that?
Another personal attack -- without a smidgeon of truth.
> I'm sure you get a lot of fan mail that fans the flames.
Yes, I get lots of nice email from nice people.
> > If you want to see a "test" Xlib that callocs all the memory instead of
> > mallocing it, why don't you go ahead and do it, if it's so important to you.
> > Why you'd demand to see that in free software is beyond me.
>
> I didn't say that: find/quote me, but don't make up things.
> (use some facts).
>
> > Moreover, the fact that you'd take the free software, find bugs, fix them,
> > but go out of your way to not give the fixes back seems mighty strange to
me.
> > Mighty strange.
>
> duh: you've told the world more than once that you aren't interested in
> the fixes.
I've never "told the world" that I wasn't interested in bug fixes.
For the guy who tells me to "use some facts" I find it strange that you would
be spreading this sort of disinformation.
Just stop.
T.E.Dickey
> I've never "told the world" that I wasn't interested in bug fixes.
that email from 1996 where you stated that you had no intention of
incorporating the fixes I made to the headers in the ddx. (Not even fixing
the uninitialized variables, I suppose - compiler warnings showed me those,
Purify would also have shown you those...).
The followup (working via Dave Wiggins to add fixes for xterm) got nowhere -
did indeed go into the "bug tracking system", but didn't affect anything in
the released X11R6.3 (I did in fact point out that I'd gotten no feedback
after that, making a guess that the changeover to TOG had something to do
with that, but you said it wasn't a factor).
(No I've not looked at X11R6.4 - but will more closely once there's patches
from it against XFree86 - I found/fixed a couple of bugs when David Dawes
imported changes from X11R6.3).
T.E.Dickey
> So really, what do you have to support your assertion that the UMRs caused by
> the pad bytes is a real problem.
now, let's get back to facts - to recap:
+ the original thread asked about Purify vs Xm/Xt/X11 libraries.
+ the responder asserted without qualification that there was no
problem.
+ I replied that it should be limited to Xm 2.x (I have a good deal
of experience with 1.2.4, unfortunately).
+ another responder claimed that 1.2.4 is just fine.
+ back/forth - you come in, saying that all of the problems have been
fixed.
As I recall, you had gone to work for XC "recently" when I started working
on xterm in January 1996. We're told that Motif 1.2.4 is 4 years old.
Perhaps you are defending the wrong version of software (perhaps not -
"recently" is a vague term).
However (in any case), I'll stick by my claims wrt Motif 1.2.4 and Purify.
During this period (since 1994) I've been chief developer in charge of a
large legacy system using that version. We've fixed all of the problems -
except for those in Xm 1.2.4, which does have a nasty habit of dumping core
5-6 levels down into the library occasionally. (The versions we're working
with are a matter of contract - telling me to "upgrade" is only cause for
amusement).
(Aside: one of the responders did note that this sort of syndrome is due
to the library rather than misuse of it - that's my opinion also - but an
opinion based on testing with Purify ;-).
kskei...@my-dejanews.com
"T.E.Dickey" <dic...@shell.clark.net> wrote:
> In comp.windows.x.motif kskei...@my-dejanews.com wrote:
> > I've never "told the world" that I wasn't interested in bug fixes.
> not addressed to "world@xxx", but XFree86 is good enough.
Well, now which is it. You started by saying I "told the world", but now you
want to qualify what you really meant? No, XFree86 is not good enough. XFree86
is XFree86 -- the world is the world. Make up your mind.
> I still have
> that email from 1996 where you stated that you had no intention of
> incorporating the fixes I made to the headers in the ddx.
Back then I told you what the priorities were, as assigned by the majority of
the members of the X Consortium and by Bob Scheifler. You may not have liked
the priorities back then, but that doesn't give you a license to defame me
and tell lies about me now.
> (Not even fixing
> the uninitialized variables, I suppose - compiler warnings showed me those,
> Purify would also have shown you those...).
> The followup (working via Dave Wiggins to add fixes for xterm) got nowhere -
> did indeed go into the "bug tracking system", but didn't affect anything in
> the released X11R6.3
What more proof do you need now to show you that the X Consortium's priorities
didn't match yours? That still doesn't give you a license to attack me
personally at this point in time.
> (I did in fact point out that I'd gotten no feedback
> after that, making a guess that the changeover to TOG had something to do
> with that.)
You, i.e. XFree86, never joined The Open Group's X Project Team. Why you
personally would have expected to be influential in setting the priorities of
the X Project Team is beyond me. We did what our paying customers wanted us to
do. I don't think that should be surprising.
All of which is way off the topic of the memory-type bugs in X11, Xt, and
Motif.
kskei...@my-dejanews.com
"T.E.Dickey" <dic...@shell.clark.net> wrote:
> In comp.windows.x.motif kskei...@my-dejanews.com wrote:
by
> > the pad bytes is a real problem.
>
> now, let's get back to facts - to recap:
>
> + the original thread asked about Purify vs Xm/Xt/X11 libraries.
>
> + the responder asserted without qualification that there was no
> problem.
>
> + I replied that it should be limited to Xm 2.x (I have a good deal
> of experience with 1.2.4, unfortunately).
>
> + another responder claimed that 1.2.4 is just fine.
>
> + back/forth - you come in, saying that all of the problems have been
> fixed.
No, I did not say all the problems had been fixed. I joined the debate by
posting an excerpt of the X11R6.4 release notes -- the part that talks to
memory error testing in X11 (i.e. not Motif).
Your response to that is preserved for posterity in Dejanews. :-)
> As I recall, you had gone to work for XC "recently" when I started working
> on xterm in January 1996. We're told that Motif 1.2.4 is 4 years old.
> Perhaps you are defending the wrong version of software (perhaps not -
> "recently" is a vague term).
Yes, "recently" is a vague term -- I started work at the MIT X Consortium in
May 1993. Not recent in real or Internet years, at least not in my book.
Wolfram Gloger
> For better, or for worse (probably for the worse), there are X interfaces
> that make it difficult to do checking of uninitialized memory references.
>
> In fact, they cannot be checked unless checked across library
> boundaries, and with DYNAMIC analysis of the execution, not static
> analysis.
Yes.
> ...
> XChangeGC is written such that it will only access members of the values
> structure that have been specified by the valuemask argument.
>
> Now, unless you have a tool which can divine that both the caller and
> the callee have actually set/accessed the values specified in the valuemask,
> which would require full dynamic code analysis to do, you aren't going
> to know if uninitialized memory was referenced.
True, but you appear to be missing an important point:
purify _does_ dynamic analysis of the execution !
I don't have the purify sources (unfortunately :-), but according to
the documentation (which seems entirely plausible), the object code of
a purified executable is modified to perform _dynamic_ checking of all
memory accesses down to the byte level. I.e., unless XChangeGC()
would access single bits in the value structure (with neighboring bits
being uninitialized), there should be _no_ UMR reports for such a
function. Unless, of course, there is a bug in purify (which is
certainly possible).
Also, it is important to note that purify never issues error messages
for _copying_ uninitialized memory (the target bytes of such an
operation simply becomes uninitialized), only for reading
uninitialized memory and then _computing_ some result from it. What
exactly this means is probably difficult to specify, and again there
may be bugs where purify thinks that an uninitialized byte is used but
really it isn't, but generally it works extremely well.
> So, guess what, a conservative tool that doesn't track the execution
> of every instruction complains about an uninitialzed value though all
> values ACTUALLY used by XChangeGC have all been initialized.
Yes, but this thread is about one of the best tools, which _does_
track the execution of every instruction.
> This is called the C programming language, folks.
You misspelled `god's' :-).
> There are better languages out there, I recommend them to your attention.
Oh no, so you've left the one true path paved by K&R and now continued
so fearlessly by BS ?
One word always comes to my mind whenever these `better' languages are
mentioned: `Sandbox' (it's even an official buzzword in one of those
languages). They may be really nice for playing, and you don't have
to worry about UMR's, double frees, memory leaks, etc. But the
performance cost is _way_ too high.
Your choice of C for the Xlib sample implementation was excellent, and
it would still be a good choice today. At least, if it was written in
anything but C, I couldn't imagine anyone would run the code in 5
years (because by that time the `better language' will be either dead
or totally different). Just MHO.
Regards,
Wolfram.
dav...@crl.com
http://www.mainsoft.com (where I used to work)
(Mainsoft's toolkit was used as Microsofts
basis for http://www.microsoft.com/ie/unix)
http://www.bristol.com (their main competitor)
http://www.willows.com (it used to exist - it might
have gone under)
All three let you recompile a Win32 app for Unix/X11.
I used to run Purify occasionally against MainWin. Since it
was not a Xt based toolkit it did not carry all that extra
baggage and we didn't cook up hokey schemes with flag bits
to say which fields were valid or not. My rule whenever using
Purify was to fix everything it complained about since otherwise
you're always drowning in noise and don't know what's what.
Occasionally our customers would show us a Purify trace and ask us to
fix certain things. I feel that if you clean it so Purify is happy -
this kind of thing will happen less often.
It's like writing the code so the compiler emits NO warnings even with
the full stringency mode turned on. You don't have to filter out
"nonsense reports" to get to the "real" problems.
However - for something as complex as a GUI toolkit it is really
hard to get it all clean. The nature of a GUI toolkit is that any
module can be called from any angle, you're at the mercy of the
developers using the toolkit as to how well they use it. It's
a tough job. In particular with Purify - there are some nooks and
crannies which seem so intricate in their coding that it is impossible
to get it all straightened out. Menu handling especially.
David
: >Yes, well, there is that. (<Silly Mode> As far religious wars go, do you know
: >of any Win32 interfaces available for Unix boxes? And if you do, do you know
: >how that interface fares under Purify? </Silly Mode>)
: There are several, I'm most familiar with Wine (http://www.winehq.com/).
: I'd be quite interested in hearing about Purify results for Wine
: or a Wine-ported application.
--
Web site creation and hosting assistance available for spiritual
healers and teachers. See http://7gen.com for more info
Douglas Ridgway
>Check
>
> http://www.mainsoft.com (where I used to work)
> (Mainsoft's toolkit was used as Microsofts
> basis for http://www.microsoft.com/ie/unix)
>
> http://www.bristol.com (their main competitor)
A Microsoft source licensee who has joined the long list of entities
suing Microsoft.
> http://www.willows.com (it used to exist - it might
> have gone under)
They are still around; but their product is LGPL now.
doug.
rid...@winehq.com
http://www.winehq.com/