[Zope] Investigating a reference leak...

[Ben Last (Zope)]

> From: Chris Withers [mailto:chris at simplistix.co.uk]

> Ben Last (Zope) wrote:
> > 1) Is there a better place than __setcache__...
> Not sure you mean __setcache__, but this is the kind of question the
> good folks on zodb-dev at zope.org maybe be able to help with...
Ouch - I mean "__setstate__" .  I believe the appropriate phrase is "D'oh!"
I'll join zope-dev and see what they have to say.

> > some particular standards for things like Image tags which the built-in tag() method can't support,
> you sure about that? tag() is pretty flexible...
Yeah, we're sure.  Our tag handling does stuff like override a GIF with a SWF for the flash version, forces the images to be served
via a dedicated images hostname, etc.  These are external requirements set on us by others...

> > 	img = getattr(self.Images,'image.gif')	#all images live in /Images, got by acquisition from self
> > 	buildTag(img.title,img.width,img.height)	#use image attributes to build fuller tag
> > 	del img						#avoid leaving references around (this is paranoid!)
> what does buildTag look like?
It's just code that builds up a full <img...> tag using the passed in parameters.  Something I did notice is that, according to the
traceback, __setstate__ is invoked on a line that reads:
	if img:
...which seems odd to me.  Is there any reason that tracebacks through ExternalMethods would dump the wrong line numbers/lines?

> Looks like something somewhere is hanging on to references.
> You could try the old fashioned way: keep commenting out bits of your
> code in small chunks until the leak goes away, when it does, analyse the
> bit you've just take out to death ;-)
Yeah... am sort of doing that by trying single URLs and watching the refcounts.  However, they don't seem to follow any strict
relationship between page templates and increases...

Thanks anyway :)
Ben