[Kst] kdeextragear-2/kst/kst

Andrew Walker arwalker at sumusltd.com
Wed Mar 16 17:28:13 CET 2005

Not sure if the previous email I sent made it hrough, so here it is again.

-----Original Message-----
From: Andrew Walker [mailto:arwalker at sumusltd.com]
Sent: Wednesday, March 16, 2005 8:27 AM
To: kst at kde.org; netterfield at astro.utoronto.ca
Subject: RE: [Kst] kdeextragear-2/kst/kst

How to repduce this problem:

If you have the main.cpp version before my latest change then
do something like:

kst gyrodata.dat -y 1 -m 99999999999

If you have my latest changes to main.cpp then do the following:

ksy gyrodata.dat -y 1 -m 10

then simply start shrinking the window down in the horizontal 
direction, until you get a crash or assert.

As the code was previously the result would crash in both
deubg and release. As it was (with George's assert) it would assert 
in debug and crash in release. The problem was not caught
and we have now released a version with this bug - when some
simple defensive programming would have prevented it.


-----Original Message-----
From: George Staikos [mailto:staikos at kde.org]
Sent: Tuesday, March 15, 2005 6:21 PM
To: netterfield at astro.utoronto.ca; kst at kde.org
Subject: Re: [Kst] kdeextragear-2/kst/kst

On Tuesday 15 March 2005 20:58, Barth Netterfield wrote:
> On Tuesday 15 March 2005 19:39, George Staikos wrote:
> > On Tuesday 15 March 2005 19:24, Barth Netterfield wrote:
> > > But I don't feel strongly enough to suggest that anyone do anything
> > > about it....
> >
> >   I'd still like to know how to see this.  That's why the assert() is
> > there.
> The point itself is more or less irrelevant, as no-one knows how to trigger
> it, but the general principle may be interesting:  How should the code
> handle 'can't imagine how it could happen, and can't see how it would be
> useful' cases like this
> i) debugging code + death to see why it happened.
> 	rational: mystries are bad.  if it happens, its probably a bug
> ii) defensive code keep it from dieing here.
> 	rational: death is bad, and maybe the code can survive the 'odd event'.
> I've done both from time to time.  In this case, I like ii....

  assert() only triggers in code compiled with debug enabled so it shouldn't 
be any problem for production use.  We can put if() on every line in Kst and 
still not avoid crashes.  The view object code was very well defined in 
behavior when I wrote it, and if things are misbehaving, I can definitely fix 
it with a crash report.  Anyway, the if() remains but I still want to know if 
it ever triggers and the only way is with assert().  Runtime checks are a 
never-ending management problem so better to avoid the need for them from the 

George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
Kst mailing list
Kst at kde.org

More information about the Kst mailing list