Bug#159023: source of better info on the memory problem - check out valgrind!
On Thu, 26 Sep 2002, Kevin Puetz wrote:
> 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 :-)
Well, the bug was really fixed in 1.10.7:
* Fix double free in modstatdb_init, in the case that modstatdb_shutdown
was called previously. Closes: #159515.
dselect calls init and shutdown several times, as you go in and out of
options. This was the real cause of the bug.
Also, I'm very well aware of valgrind. Take a look at the changelog for
1.10.5, which was mainly driven by valgrind.
Reply to: