ok, using libmem to fix a leaking hash table implementation.
- see 06.badhash/README for scenario
- in summary, when you run something like:
   time ./iterate 8000 10
- you'll see that:
  - iterate's memory grows continuously to larger than the
    machine's physical memory,
  - tops out at about 80% of physical memory, the system
    won't let it have more,
  - the system starts swapping (%wait goes busy),
  - machine goes very slow!  high load average
  - all processes slow, not just iterate!
- now we strongly suspect that the hash module is leaking
  some memory, failing to free everything that it mallocs.

- debug this via libmem
- as before:
  - append -lmem to LDLIBS in the Makefile
  - edit *.c and add #include <mem.h> to each
  - rebuild using 'make clean all'
  - run ./testhash [simpler test program]
  - 2 non-freed 256K chunks.
  - line nos of malloc()s that are not freed:
  File          Line    Size
  hash.c  	114     260264
  hash.c  	75      260264
  - look at those two lines:
    - line 75 is in hashCreate():
      h->data = (tree *) malloc( NHASH*sizeof(tree) );
    - and line 114 is nearly identical in hashCopy().

  - hypothesis: we suspect that hashtable->data is freed.
  - find the "hash free" function, it's called hashFree().
    look carefully inside, and you'll find the missing free.

  - BUG FOUND.  fix it, recompile.
  - ./testhash now reports no unfree()d blocks.
  - check small values of N in iterate: ./iterate 1,
    ./iterate 2, ./iterate 3..  no unfree()d blocks.
  - check the large scale case:
  - use ./testme shell script to try several values of N
  - linear behaviour back again!
  - job done!  libmem rocks!
