On Sat, 2007-05-26 at 18:45 +0100, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Jon Burgess <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-05-26 at 10:52 +0100, Tom Hughes wrote:
> >
> > > In message <[EMAIL PROTECTED]>
> > > [EMAIL PROTECTED] (Jon Burgess) wrote:
> > >
> > > It is worse than that though, because if the node which the
> > > attribute is attached to is freed then the attribute will be
> > > freed (even if there are other references to it) and there is
> > > no easy way to find out which attributes need to be kept.
> > >
> > > I guess you would have to walk the entire node tree checking
> > > the _private reference count of each attribute and unlinking
> > > anything that is shared before freeing the node?
> >
> > I'm only just starting to get my head around the interaction between C
> > and the ruby objects and GC. The patch below seems to be a simple fix
> > but I'm by no means certain this fixes the more general problems.
> >
> > I think it works because the GC implicitly performs the reference
> > checking for the case you mention.
>
> Nope. As soon as I fixed the memory leak mentioned in my other
> thread (which is behind at least some of the OpenStreetMap memory
> leak issue that I assume we're both looking at) I started getting
> crashes because the node tree was being free leaving orphaned
> ruby attribute objects that pointed at libxml attribute objects
> that had been deleted.
Yes, I'm looking at it from the OSM angle too. Would you mind sharing
your initial fix and test case?
> I'm working on a plan at the moment, but it currently involves
> reworking the whole basis of how nodes and attributes are managed...
I'm working on which sounds similar. It is tricky to get libxml and the
GC working together successfully.
Jon
_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
