GC and security

[Tim Peters]

[Aahz]
>> Assuming you're talking about CPython, strings don't really participate
>> in garbage collection.  Keep in mind that the primary mechanism for
>> reaping memory is reference counting, and generally as soon as the
>> refcount for an object goes to zero, it gets deleted from memory.

[Les Schaffer]
> ok so far ...

Not really ;-)  Refcounting is /a/ "garbage collection" technique, and
drawing a distinction between refcount-based reclamation and other
ways CPython reclaims memory has no bearing on your question.

>> Garbage collection only gets used for objects that refer to other
>> objects, so it would only apply if string refcounts are being held by
>> GC-able objects.

> you lost me by here ...

That tends to happen when an irrelevant distinction gets made ;-)

> is there something different about string objects than other objects in
> Python?

Not anything relevant wrt garbage collection.  It may be relevant that
strings are immutable, since that prevents you from overwriting a
string's contents yourself.

> are you saying EVERY string in Python stays in memory for the lifetime
> of the app?

He wasn't, and they don't.

>> Also keep in mind, of course, that deleting objects has nothing to do
>> with whether the memory gets overwritten...

> no chance of being overwritten until deleted, no?

True.

> and once deleted over time there is some probability of being
> overwritten, no?

True.  Also true if you add the intended "non-zero" qualifier to
"probability" ;-)

> and i am curious how that works.

Purely accidental -- nothing guaranteed -- details can (& do) change
across releases.  Read obmalloc.c for a tour of the accidents du jour.

> it sounds like you are saying once a string, always the same string, in python.
> if thats true, i am glad i know that.

Not true, so be glad to forget it.

A curious possibility:  if you do a debug build of Python, obmalloc.c
arranges to overwrite all of an object's memory as soon as the object
is reclaimed (by any means, refcounting or otherwise).  That wasn't
for "security" (faux or otherwise), it's to make it easier to detect
buggy C code referencing freed memory.