Re: valgrind/dselect questions
On Sat, 2006-10-28 at 15:16 -0600, Bruce Sass wrote:
> Hi,
>
> On Thu October 26 2006 09:54, Ian wrote:
> > Bruce Sass writes ("valgrind/dselect questions"):
> > > Figuring it would be a good learning experience to try out the
> > > recent patch for bug #395140 I applied it, installed the result,
> > > did:
> >
> > dpkg and dselect have some custom memory allocation stuff. When I
> > wrote it it was hand-rolled but it was replaced by use of GNU
> > obstacks at some point :-/.
> >
> > That would be top of my list of changes to back out.
>
> Is that because pooled memory is not a good strategy for dpkg and
> dselect, or something intrinsic to GNU obstacks?
I'm guessing the latter: with obstacks, you can only free objects in
reverse order of allocation. So, if you allocate A, B, and C, you are
not allowed to deallocate B until you first free C. This model works
well for certain specific applications, but not for general allocation
needs.
> I am assuming the small bit of code I was able to "valgrind" is not
> leaking memory because, since it is still reachable, the kernel will
> free it up. So, maybe sloppy code but not really a problem.
Actually, the kernel will free up unreachable memory as well: everything
in a process's VM space will be freed.
The problem with unreachable memory is not that the kernel won't free
it, but that the application itself can't possibly. So, for programs
that tend to run for long periods, the memory usage tends to just keep
creeping up. This may apply less to dpkg/dselect than to, say, Apache
httpd.
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Reply to: