Inspired by Knuth’s example of “The Errors of TeX” in Software – Practice and Experience. This is an attempt to capture the errors I made in SortTables software; my most common problem is carelessness, especially in reorganizing data structures. <\/p>\n
Date:<\/b> date
Symptom:<\/b> the-symptom
Cause:<\/b> the-cause
Fix:<\/b> the-fix
Lesson:<\/b> the-lesson<\/p>\n
\n
Date:<\/b> 8-2-95<\/p>\n
Symptom:<\/b> System printed endless series of blank lines.
Running in the debugger showed it failed in PatternIndex when it
tried to close the pattern file.<\/p>\n
Cause:<\/b> Didn’t note.<\/p>\n
Fix:<\/b> Didn’t note.<\/p>\n
Lesson:<\/b> Didn’t learn:)<\/p>\n
\n
Date:<\/b> 7-31-95<\/p>\n
Symptom:<\/b> Assertion violation (iterator had pos==-1). Came
about after cutting one or more columns in a ListResult.<\/p>\n
Cause:<\/b> Had started to move from managing the ListResult as
an array of buckets to a tree of buckets. To do this, had an array
twice the size needed, with the leaves starting at
array[num_buckets]. Unfortunately, one of the routines was relying
on looking at the array starting at array[0].<\/p>\n
Fix:<\/b> Make it consistently start at 0. Put off tree stuff for
now.<\/p>\n
Lesson:<\/b> Don’t make partial changes in data structure –
either finish the new implementation or don’t put it in.<\/p>\n
\n
Date:<\/b> 7-29-95<\/p>\n
Symptom:<\/b> “And”-ing together several lists showed the list
always being left all true. At first it looked like the data might
be that way, but checking more carefully showed that certain bits
should be left cleared.<\/p>\n
Cause:<\/b> The andWith()<\/tt> method was working properly to
clear bits but not set them. The value (0 or 1) was being
left-shifted and negated for and-ing in, but when the value was 0,
there was no bit set to shift, so nothing ever got left out.<\/p>\n
Fix:<\/b> Change formula to use “1” rather than “value”.<\/p>\n
Lesson:<\/b><\/p>\n Date:<\/b> 7-17-95<\/p>\n Symptom:<\/b> SortTables locks up – apparent infinite loop.<\/p>\n Cause:<\/b> It was an infinite loop. Had added a Fix:<\/b> Don’t just look at the last object, remove it from the Lesson:<\/b> Watch use of functions with similar names (here Date:<\/b> 6-23-95<\/p>\n Symptom:<\/b> After switching from “big” to “small”, the items in Cause:<\/b> Reset the column # in the new set to 0; should have Fix:<\/b> Update that number to proper value.<\/p>\n Lesson:<\/b> Make sure every data is set in constructors!<\/p>\n Date:<\/b> 6-23-95<\/p>\n Symptom:<\/b> After shift in representation from “big” to Cause:<\/b><\/p>\n Fix:<\/b><\/p>\n Lesson:<\/b> Need to be very careful on manual code Date:<\/b> 6-22-95<\/p>\n Symptom:<\/b> Screen repeated blank lines (memory trap in Cause:<\/b> Had set up system to start shifting representations Fix:<\/b> “Defined the problem away” by making a rule that Cut or Lesson:<\/b> Don’t switch things halfway. Remember that iterators Date:<\/b> 6-21-95<\/p>\n Symptom:<\/b> Had converted a set of classes to Coplien’s Cause:<\/b> Needed to initialize _rep to NULL in “letter” Fix:<\/b> Set _rep=NULL.<\/p>\n Lesson:<\/b> Watch effects on all parts of class data when Date:<\/b> 6-19-96<\/p>\n Symptom:<\/b> SortTables: deleting records before a point didn’t Cause:<\/b><\/p>\n Fix:<\/b> Adjust count as well; return proper position; sort Lesson:<\/b> Could have probably caught this with some invariant. Date:<\/b> 6-16-95<\/p>\n Symptom:<\/b> Died in memory allocation. Said the “record_set” Cause:<\/b> Had moved a field from child to parent, but forgot to Fix:<\/b> Delete child version.<\/p>\n Lesson:<\/b> Watch editing habits!!<\/p>\n Date:<\/b> 6-16-95<\/p>\n Symptom:<\/b> First record wasn’t shown, last record was blank. Cause:<\/b> Had messed up ListIterator to return record numbers Fix:<\/b> Not ideal, but moved the “encoding” up to the display Lesson:<\/b> Keep hacking isolated to the place where it’s Date:<\/b> 6-15-95<\/p>\n Symptom:<\/b> Reading records by looking at offset+length in Cause:<\/b> When writing the file originally, had cut-and-paste Fix:<\/b> Change variable name to match.<\/p>\n Lesson:<\/b> Bad symptom – spreading knowledge of endianness Date:<\/b> 6-15-95<\/p>\n Symptom:<\/b> Debugging output – label appeared but rest of Cause:<\/b> Left out a format specifier in printf.<\/p>\n Fix:<\/b> Put it in.<\/p>\n Lesson:<\/b> Watch printf (as usual). Surprising the compiler Date:<\/b> 5-29-95<\/p>\n Symptom:<\/b> Re-loading a file caused a trap.<\/p>\n Cause:<\/b> Had created a bitvector from static storage to reduce Fix:<\/b> Let “BitVector” object allocate the storage Lesson:<\/b> Don’t put off today… Profile before worrying about Date:<\/b> 5-12-95<\/p>\n Symptom:<\/b> Getting wrong values for min & max<\/p>\n Cause:<\/b> Moved min\/max init. code around, but in one that sets Fix:<\/b> Add next_column() and reset_column() calls.<\/p>\n Lesson:<\/b> Watch initialization.<\/p>\n Date:<\/b> 5-8-95<\/p>\n Symptom:<\/b> Triggered assertion violation in display.cc.<\/p>\n Cause:<\/b> Added _col_is_restricted to decide whether I had an Fix:<\/b> Change so that counting adjusted columns is independent Lesson:<\/b> Things keep getting caught in display.cc; but the Date:<\/b> 5-8-95<\/p>\n Symptom:<\/b> Complaints about undefined externs Cause:<\/b> Choosing header files is tricky. Part of the problem Fix:<\/b> Ensure that “Universal_include.h” is the first Date:<\/b> 5-8-95<\/p>\n Symptom:<\/b> Triggered an assertion violation in display.cc.<\/p>\n Cause:<\/b> Adding PositionPool: set up a default size of Fix:<\/b> Make PositionPool request FileArray of the proper Lesson:<\/b> Tough one. Need fixed-size entities for performance Date:<\/b> 5-3-95<\/p>\n Symptom:<\/b> Moved system to Alpha, didn’t work. Problems on Cause:<\/b> Same problem again: had a couple “long”s in place. Fix:<\/b> Redo repairs; check diffs.<\/p>\n Lesson:<\/b> Better config mgmt.<\/p>\n Date:<\/b> 3-2-95<\/p>\n Symptom:<\/b> Moved system to Alpha (64-bit int), didn’t Cause:<\/b> Used “long” and “int” for types w\/assumed 32-bit Fix:<\/b> Define length-specific types depending on system. Use Lesson:<\/b> Ongoing problem with C types. Almost always get pain Date:<\/b> 2-27-95<\/p>\n Symptom:<\/b> Tried to substitute a “word wrapping” window for Cause:<\/b> Had put a “break” in for debugging; this caused only Fix:<\/b> Remove break. Check length first.<\/p>\n Lesson:<\/b> Be careful with debugging code. Maybe always add a Date:<\/b> 2-24-95<\/p>\n Symptom:<\/b> Deleted all but those records starting with “c”. Cause:<\/b> “prevFor” routine computed a loop moving back through Fix:<\/b> Test right thing in loop.<\/p>\n Lesson:<\/b> This came from leaving “dead” variables around from Date:<\/b> 2-24-95<\/p>\n Symptom:<\/b> After deleting lines, the approximate factor went Cause:<\/b> Used “%” instead of “\/” to round off.<\/p>\n Fix:<\/b> Use “\/”.<\/p>\n Lesson:<\/b> Check math functions manually.<\/p>\n Date:<\/b> 2-24-95<\/p>\n Symptom:<\/b> Searching for “1” in the year column, with a bunch Cause:<\/b> Comparison function in binary search – took min of Fix:<\/b> Don’t take min.<\/p>\n Date:<\/b> 2-24-95<\/p>\n Symptom:<\/b> Final “statistics” output showed objects not Cause:<\/b> The re-load routine created a new result set and Fix:<\/b> Use calloc of initial space to ensure empty pointers, Date:<\/b> 2-13-95<\/p>\n Symptom:<\/b> Computing min and max for a series of buckets which Cause:<\/b> Computed bucket number wrong (should have been Fix:<\/b> Change computation.<\/p>\n Date:<\/b> 2-13-95<\/p>\n Symptom:<\/b> Computing min and max for a series of buckets which Cause:<\/b> Realized that if I had a bucket only partially Fix:<\/b> Added assertion code to FileArray to ensure only valid Date:<\/b> 2-13-95<\/p>\n Symptom:<\/b> Getting a bucket for which max < min; bucket is Cause:<\/b> In figuring left-over “-1” values to write to bucket, Fix:<\/b> Test for exactly-full bucket.<\/p>\n Date:<\/b> 2-3-95<\/p>\n Symptom:<\/b> Destructor didn’t run right.<\/p>\n Cause:<\/b> Had added a new parent class with a definition Fix:<\/b> Change “=0;” to “{}”.<\/p>\n Lesson:<\/b> Spend a little more time learning C++. Would have Date:<\/b> 2-2-95<\/p>\n Symptom:<\/b> Line put on screen didn’t get put in list of Cause:<\/b> List object was designed for pointer objects, and Fix:<\/b> Don’t let 0 occur; add 1 to value before letting it out Date:<\/b> 1-20-95<\/p>\n Symptom:<\/b> Screen just keeps dumping blank lines.<\/p>\n Cause:<\/b> Trying to introduce a new “iter” variable. Had Date:<\/b> 1-20-95<\/p>\n Symptom:<\/b> Lines not displaying right when moving just off Cause:<\/b> Deleted old line from list, used “count()-1” to tell Fix:<\/b> Since list was reduced in size already, should have Date:<\/b> 1-4-95<\/p>\n Symptom:<\/b> Program seemed to run OK but complained when Cause:<\/b> The sort comparison for a qsort was backwards; result Date:<\/b> 1-4-95<\/p>\n Symptom:<\/b> Sorted items appeared out of order.<\/p>\n Cause:<\/b> Sorting was done on an illegal field. The field SortTables Error Log Inspired by Knuth’s example of “The Errors of TeX” in Software – Practice and Experience. This is an attempt to capture the errors I made in SortTables software; my most common problem is carelessness, especially in reorganizing data structures. Date: dateSymptom: the-symptomCause: the-causeFix: the-fixLesson: the-lesson Date: 8-2-95 Symptom: System printed endless series […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[10,13,11,14],"tags":[],"class_list":["post-46","post","type-post","status-publish","format-standard","hentry","category-dissertation","category-refactoring","category-sorttables","category-testing"],"yoast_head":"\n\n
have exposed this.<\/li>\n
main()<\/tt> routine, but that was never updated when the
andWith()<\/tt> method was added. The simplest test would have
exposed this.<\/li>\n<\/ul>\n
\n
cList_freeObjects() method, that looked at the last object, for as
long as there were objects. Since it looked but didn’t remove the
object, list never shrank, and it just kept looking.<\/p>\n
list.<\/p>\n
cList_lastObject() vs. cList_removeLastObject().)<\/p>\n
\n
the small set aren’t ordered properly.<\/p>\n
left it at same column # as old set (otherwise throws off display
and others about where things are; change in rep should be
transparent to clients).<\/p>\n
\n
“small”, items in the small set were not in order. Moving
cursor-down jumped around rather than going one at a time.
Investigation revealed the table structure in TableResult had
_ptable[0]==_ptable[1] (not good for a permutation). Added a check
for this, so it would die the first time that happened. However, in
the debugger, when TableResult’s ResultSet-based constructor is
called, it ends up with suspicious pointers.<\/p>\n\n
simple array. Had assumed that a circular list was necessary, but
in fact this was never the case. Removed that assumption, so now it
just assumes an arbitrary starting point.<\/li>\n
a for-loop-based iterator to a while-loop one. Had the “next” at
the bottom of the loop rather than the top.<\/li>\n<\/ul>\n\n
transformations.<\/p>\n
\n
debugger).<\/p>\n
when size changed dramatically, by applying Coplien’s
letter-envelope idiom. Had changed uses of ResultSet so it was an
envelope. However – the result set has an associated iterator that
must be changed as well.<\/p>\n
Match operations (the destructive ones) invalidate existing
iterators, thus pushing the problem onto their clients.<\/p>\n
and collections are closely tied together. Be careful with
envelope-client idiom; it’s what’s needed here because we’re
switching types, but it brings a lot of baggage. Probably better
off with a separate “rep” hierarchy.<\/p>\n
\n
envelope-letter structure. After trying to do a reload of the data
(within running program), just started printing blank lines
“forever”. Debugger showed this as dying in the base class
destructor.<\/p>\n
classes. Otherwise, it has garbage value even though it isn’t
used.<\/p>\n
re-organizing.<\/p>\n
\n
delete any records.<\/p>\n\n
copying the array) to an array treated as a circular list. Made
“deleteBefore” parallel to “deleteAfter” only it updated the start
rather than the count. BUT – deleteBefore changes both start and
count where deleteAfter really does only affect count.<\/li>\n
the starting position.<\/li>\n
proper list.<\/p>\n
BUT – really need to walk through all class data and make sure of
which things an operation affects.<\/p>\n
\n
field had a bad value. Examining *this showed it as being ok.<\/p>\n
delete it from child.<\/p>\n
\n
When moving to other columns, items were scrambled.<\/p>\n
starting with 1 rather than 0, because the display routine used a
list that was designed for pointers and couldn’t store items with
value 0.<\/p>\n
routine that wanted to use the list. Ideally, we’d use a list that
handled integers properly.<\/p>\n
needed. Use proper tools. (Don’t want to change the List class
because it works as documented for the NeXT list class; but it
would be better to have a “real” list class for integers.)<\/p>\n
\n
file. What should have been a short field was a long string
containing more than one record.<\/p>\n
code to write a proper-endian number. But – the value to be written
was in a different variable.<\/p>\n
around. Watch cut-and-paste.<\/p>\n
\n
information didn’t.<\/p>\n
didn’t catch it – it was a constant string, compiled with -Wall.<\/p>\n
\n
costs of initializing it to all 0’s. (static data defaults to 0.)
Had intended to re-clear this storage when object was deleted
(rather than created) – but never did.<\/p>\n
dynamically; profile to see if it matters. (If so, go back to
“clear on delete”.)<\/p>\n
efficiency. (Although I think I may have tagged that at one point
as being a valid efficiency concern.) Keep notes – use TBD comments
to record intentions.<\/p>\n
\n
initial values didn’t properly change columns while setting them.
Some lower-level code relied on actual column number to know what
to fetch, so everything was based on column 0.<\/p>\n
\n
exact or approximate count, set true whenever _bounds_xxx[]
changed, and tested on each loop over them. BUT: this precluded
adjusting the bounds when a column changed.<\/p>\n
of bounds[] setting. Now _col_is_restricted[] tells whether there
was an explicit restriction on THIS column.<\/p>\n
problem is happening in the interaction between ListResult.cc and
ListIterator.cc. Need something that can move the assertions back
down there to catch problem closer to point of call.<\/p>\n
\n
“read\/open\/etc”.<\/p>\n
is inconsistency & non-standard choices.<\/p>\n
inclusion in each .cc.<\/p>\n
\n
LISTRESULT_MAX_DIMS for size of cached items. Unfortunately, file
was organized by size being the current actual number of
columns.<\/p>\n
size.<\/p>\n
reasons, but variable-sized ones out on disk. Need to think this
through.<\/p>\n
\n
very large data set on ei.cs.<\/p>\n
The real cause is poor configuration management: changes on fir\/ST5
were not put back into jingluo\/ST5, and jingluo\/ST5 become
jingluo\/ST6 with “old” code.<\/p>\n
\n
work.<\/p>\n
sizes. Had also used “raw” machine order to write binary files.<\/p>\n
ntohl() and htonl() to define FROM_BIG_INT32() and TO_BIG_INT32()
macros. (Probably not good names).<\/p>\n
from depending on raw types. Need smoother handling of binary I\/O.
(Changed to convert on fly here, probably shouldn’t do unless
necessary.)<\/p>\n
\n
item display in sorttables. Random words appeared everywhere in
window.<\/p>\n
1 line to be attempted for display. Tried to display line via a
count “MAXLINES”, but didn’t check actual length of screen, so was
grabbing random characters.<\/p>\n
comment “\/\/ DEBUG” to the end of the line. Be a little more ready
to use the debugger rather than dropping into code mods.<\/p>\n
\n
Was ok. Moved to the end. Died when moving directly back to the
front.<\/p>\n
list but tested the original argument rather than the working value
that was being modified in the loop. (Lucky it wasn’t an infinite
loop.)<\/p>\n
the parameter. I’ve tended to treat parameters as “read-only”.
Maybe I should revise that. This is sort of a const-correctness
issue too – the parameter in question wasn’t marked const though
there was no intent to change it. Finally – it’s funny the compiler
didn’t notice and warn that loop control could never change.<\/p>\n
\n
up by a huge amount.<\/p>\n
\n
of blank entries first, it didn’t move until “199” was typed even
though “1888” was in the list first.<\/p>\n
two lengths, when it really should have considered the whole
pattern.<\/p>\n
\n
deleted. This happened when “@” was used to re-load a file.<\/p>\n
iterator but didn’t delete any old ones.<\/p>\n
make re-load delete old before creating new.<\/p>\n
\n
are permutations of record numbers. But when running, got an error
about finding a record which was already in an unchanged list.
Checked min-max list, and found that after the first column’s worth
of buckets, all buckets had same min-max values. (Shouldn’t be
possible since it’s a permutation.)<\/p>\n
i*columns not i*columns*capacity).<\/p>\n
\n
are permutations of record numbers. But when running, got an error
about finding a record which was already in an unchanged list.
Checked min-max list, and found that after the first column’s worth
of buckets, all buckets had same min-max values. (Shouldn’t be
possible since it’s a permutation.)<\/p>\n
filled, I would be trying to look up bucket #-1 which can’t
exist.<\/p>\n
indexes used, changed calling code to detect “-1” and skip that
non-record. BUT: This doesn’t affect the original problem.<\/p>\n
\n
completely filled with -1 values.<\/p>\n
didn’t consider case that last bucket filled in perfectly.<\/p>\n
\n
“virtual ~EnvoyFactory () = 0;”. But destructors should not be
abstract.<\/p>\n
been nice to have a compiler warning on that one.<\/p>\n
\n
displayed lines. This caused the system to allow backward scrolling
(“haven’t hit that line yet”).<\/p>\n
assumed NULL could never be put in list. Using it for int objects,
where value 0 was legal and occurred.<\/p>\n
to clients, subtract 1 on use.<\/p>\n
\n
prototyped it with a simple global. Then tried to pass right iter
around, but left it off an argument list, so it picked up the
defunct (un-initialized) global one.<\/p>\n
\n
screen. Should scroll one line but didn’t scroll at all until two
down-arrows; might have corrupted some of screen data with wrong
line, too.<\/p>\n
where new line should be, then added new line to list.<\/p>\n
used “count()” instead.<\/p>\n
\n
deleting an array at the end.<\/p>\n
of the sort was compared assuming “ascending” but sort yielded
“descending”. This was causing storage to get trashed.<\/p>\n
\n
counter should have been wrapped to 0 when it reached the maximum,
but was incremented instead.<\/p>\n","protected":false},"excerpt":{"rendered":"