While I can understand your general sentiment, allowing minor problems like this to clutter the output from valgrind makes spotting the real errors amidst the noise more difficult. Eventually, when enough of these types of problems exist, valgrind stops being used altogether, because it's too time consuming to inspect the output.
In short, I guess my point is that this kind of thing is another example of "broken window syndrome" - keeping the small things tidy makes everyone more likely to keep the big things tidy too. -Tom > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, October 03, 2005 9:03 AM > To: sqlite-users@sqlite.org > Subject: Re: RE: [sqlite] SQLite kind-of memory leak (PATCH) > - bug reports > > "Griggs, Donald" <[EMAIL PROTECTED]> wrote: > > > > > > I'm using valgrind for checking for memory leaks in SPL. When > > > profiling scripts which do access SQLite databases, I've > found that > > > the lockHash and openHash data structures in os_unix.c > don't get freed. > > > > > > I wouldn't consider that a real memory leak, but it > doesn't look nice > > > in memory profilers such as valgrind. That's why I recommend the > > > attached patch. Please let me know how you think about it.. > > > > > > > You are right: this is not a real memory leak. > > I am disinclined to add code to SQLite that serves no purpose > other than to make the output of valgrind look better. valgrind > is a nice tool for tracking down memory allocation problems. > (SQLite uses a different mechanism, but that should not be > taken as a slight by valgrind.) But I do not believe that > valgrind should become an end in itself. I will certainly make > whatever changes to SQLite are necessary to fix *real* memory > leaks. I would even be willing to modify existing code to > better suit valgrind as long as it doesn't add complexity > or have a run-time cost. But the changes submitted do have > a run-time cost, and while that cost is very small (perhaps > even unmeasurable) it is finite. We have worked *very* hard > to remove such minor costs from SQLite and it would be a shame > to add them back, just so that the output of a diagnostic > tool could look nicer. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
