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; |
<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.
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.
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/
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/
> 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
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.
> 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.
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.
> 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
> 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/
--
: 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?
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.
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.
> 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)
> 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 ;-)
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
> 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
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.
>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
: 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
> 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
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.
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.
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
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.
Ah, but that's a UMR that shouldn't be ignored. Purify is a win here.
> 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).
You mean way back in Motif 1.0, which became obsolete in 1991?
Motif is now at 2.1.10, using X11R6.
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
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
> 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
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
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
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
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
Complain to them! There's really no reason that you should put up with
software several *years* out of date.
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
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.
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
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.
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
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 |
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 ;-)
> 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
> 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.
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
> 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)