Re: [caudium-devel] Auditing caudium.c : f_parse_query_string()

[Marek Habersack <grendel AT caudium.net>]

* Bill Welliver 
<hww3 AT riverweb.com>
 [060131 17:25], scribbled:
> > Not unless some other code requested a string with the same value - then
> > they will share a copy.
> >
> 
> But I guess that's my question... if the only things _we_ allocate on
> the pike side are the array query, and the mapping variables and multiset
> unset (both of the latter should be freed after each loop, right), what
> else could be holding that many of the strings we've created? We're just
> running this in hilfe, and I suspect it would be the same if I just ran
> it in pike.
Well, in the case of Caudium what you're saying might be true, but in a
general case the assumption that we're the only ones accessing the strings
cannot be made, imho. Also, even in Caudium we call various APIs which might
hold a reference to a string so that still might be a problem outside
Caudium. That's why, I think, printing object (string) id and its refcount
could be of advantage in detecting what's happening. As an aside, I wonder
what happened to the Pike debugger Hubbe once made? It might come useful in
that we could learn how to set breakpoints in the Pike code, i.e. instrument
the code - that would help us detect what's happening to the strings.

> I verified that it's not some variable we accidentally have left around in
> bertrand's test method, so there does appear to be something goofy with
> that method.
I don't know what kind of garbage collector the Pike one is, but generally
there are two kinds:

 - precise: where the garbage collector knows exactly about each memory
   pointer and makes it impossible to mistakenly account non-used memory as
   used one (such pointers are sometimes called managed pointers)

 - conservative: in this case, the garbage collector usually checks whether
   a pointer address is within the program's allocated address space and
   can, and very often does, misinterpret an actually dead pointer as a live
   one - which leaks memory. 

So, if Pike uses the latter then despite the refcount being zero, the
pointer may still be left in the memory.

marek

Attachment: signature.asc
Description: Digital signature