Bug#159023: source of better info on the memory problem - check out valgrind!

[Kevin Puetz <puetzk@iastate.edu>]

I don't have a dselect that hasn't been stripped (so the trace is mostl 
useless, lacking all symbol nams) but valgrind (a memory debugging tool 
available in unstable) reveals a large number of off-by one memory accesses 
in dselect, so I suspect your guess is right. It also found about a meg of 
memleaks, so the free is probably important :-)

all seem connected to uses of memcpy on things which have been realloc'ed 
going 1 byte past the end, so I'm guessing a bunch of string manipulations 
are forgetting to account for the space used by the '\0'.

valgrind --gdb-attach=yes will cause a break to gdb (otherwise, it'll just 
print the backtrace+linenumbers and resume) on the offending line whenever 
this occurs, so given a debug-symbol build of dselect fixing this right 
shouldn't be all that difficult. And it removes a whole class of random 
bugginess, which is always a good thing :-)

These bugs used to be almost impossible to find (hence I can see why you just 
gave up and removed the free) but nowadays you just need to know about 
valgrind. It loves you. A lot :-)

to get a good log just do something like
     valgrind --logfile-fd=3 dselect 3> /tmp/valgrind-log
or to stop the debugger on each bad memory access
     valgrind --gdb-attach=yes dselect
and do whatever you triggers the crash. The app shoud startup and run normally 
(well... about 5-10x slower than usual) and either log or break on the true 
guilty party (rather than on the crash much later). the log I took shows (but 
couldn't identify, due to lack of symbols) a fair number of suspects, so 
hopefully this will let it be fixed right :-).