In message <[EMAIL PROTECTED]>
Marc Munro <[EMAIL PROTECTED]> wrote:
> I have a reproducible crash using libxml. I'd like some suggestions on
> how I can track this down as it's become a show-stopper for my current
> project. This is from a libxml gem created from svn this morning.
Your
This is most likely related to a copy node bug which has been fixed in a .4
release. Ross fixed per an issue I opened. Although the .4 release is
labled as a pre-release, it is stable with the exception of the memory bug.
Upgrade and it will most likely fix the problem.
See issue #4635 (now clo
On Thu, 2007-23-08 at 07:33 -0400, Doug Bryant wrote:
> This is most likely related to a copy node bug which has been fixed in
> a .4 release. Ross fixed per an issue I opened. Although the .4
> release is labled as a pre-release, it is stable with the exception of
> the memory bug.
>
> Upgrade
Tom,
Your crash is a typical one - it looks like it is caused by ruby
still having a handle to a libxml object that has been attached to
another libxml object that has then been freed.
Would the solution be a simple as having ruby nodes *never* freeing
libxml objects except the toplevel docum
On Thu, 2007-23-08 at 10:45 -0600, Charlie Savage wrote:
> Would the solution be a simple as having ruby nodes *never* freeing
> libxml objects except the toplevel document (since it sounds like libxml
> cleans up after itself).
Not all nodes wind up in documents, so unless you're prepared for
The problem is that some nodes are allocated by libxml by parsing
documents, processing xsl, etc, and some directly by ruby. I think the
hybrid approach is necessary in order to get the speed benefits of using
libxml, and I think a hybrid approach to freeing is therefore necessary.
It does seem t
On Thu, 2007-23-08 at 11:13 -0600, Charlie Savage wrote:
> Ah - interesting. A hybrid approach is extremely difficult because it
> means you have to keep track of the ruby to libxml object mapping. For
> example, say you have some ruby code that create a libxml node. That
> ruby object would
The problems that I have discovered stem from libxml freeing entire
document trees while there are still ruby objects referencing the nodes.
When those ruby objects are subsequently garbage-collected, the xmlNodes
in those objects have already been freed and sadness ensues. But I
think the curren
Seems the python community has some of the same issues.
http://web.archive.org/web/20041010012053/www.dwerg.net/2004/articles/libxml
http://web.archive.org/web/20041010012802/www.dwerg.net/2004/articles/morelibxml
smime.p7s
Description: S/MIME Cryptographic Signature
___
Dear Devs,
Need to make a decision about the Repo layout. The two cases are:
branches/
tags/
trunk/
libxml/
libxslt/
or
libxml/
branches/
tags/
trunk/
libxslt/
branches/
tags/
trunk/
If the first case, the versions of libxml and libxslt would always b
Dang! And I really intended to butt out of this discussion :-)
On Thu, 2007-23-08 at 12:14 -0600, Charlie Savage wrote:
> > The problems that I have discovered stem from libxml freeing entire
> > document trees while there are still ruby objects referencing the nodes.
> > When those ruby objects
In the second case the version numbers can diverge. So it allows a
little more independence between the two libs. The downside is that
one has to keep track of which version of libxml to use for a
particular version of libxslt. Not a big deal, really, but there it is
nonetheless. Also, something t
In message <[EMAIL PROTECTED]>
Charlie Savage <[EMAIL PROTECTED]> wrote:
> > The problem is that some nodes are allocated by libxml by parsing
> > documents, processing xsl, etc, and some directly by ruby. I think the
> > hybrid approach is necessary in order to get the speed benefits o
In message <[EMAIL PROTECTED]>
Charlie Savage <[EMAIL PROTECTED]> wrote:
> > The problems that I have discovered stem from libxml freeing entire
> > document trees while there are still ruby objects referencing the nodes.
> > When those ruby objects are subsequently garbage-collected, th
In message <[EMAIL PROTECTED]>
Marc Munro <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-23-08 at 11:13 -0600, Charlie Savage wrote:
> > Ah - interesting. A hybrid approach is extremely difficult because it
> > means you have to keep track of the ruby to libxml object mapping. For
> > examp
Simple - you create an element object in ruby, then add that element
as the child of another element. The ruby element object still exists
and still points at the same element though (and can be used to make
changes to that element in the tree).
Is this avoidable by unsetting the Ruby object's f
I don't know if libxml2 provides such callbacks, but I don't see how
this would work anyway. The xmlNode has no idea what ruby objects are
referencing it.
Right - you have to add in mapping between Ruby objects and libxml
objects (its a hash table keyed on the C pointer having pointers to the
On Thu, 2007-23-08 at 13:04 -0600, Charlie Savage wrote:
> >
> Instead of trying to ensure that we free the ruby
> > object when the xmlNode is freed, we have to ensure that such nodes
> > referenced by ruby objects are not freed at all by xmlFree.
>
> Boy - that's tough in a tree. What if you
I'm not sure why this seems tough. If we have a reference to a leaf
when we want to garbage collect the rest of the tree, I am suggesting
removing that leaf from the tree prior to freeing it.
You don't view the tree as atomic? Seems to me it is.
When you add the Ruby objects to a tree, the Ru
On Thu, 2007-23-08 at 13:48 -0600, Charlie Savage wrote:
> I don't think your Ruby code would change at all. Under the covers, the
> bindings would see that you are adding root to to doc, and so the Ruby
> object pointing to root would give up ownership.
>
> You'd then setup a mark function fo
So, when can you have it ready ;-)
Hah. Let's what other people think - I could be way off base since I
haven't looked in-depth at the bindings code. Thoughts everyone?
If this idea has merit, then the trickiest bit would be making sure
there is a one-to-one Ruby document object to libxml
> For SWIG I implemented support for mapping between C pointers and
> Ruby objects by using a Hash Table (ruby's built in one,
> st_table). That allows you to enforce a one-to-one Ruby to C
> object mapping. Do we want to do something like that here?
It doesn't exist now and I'm inclined
> My patches (to which I see you have already been pointed) are quite
> likely to help with this. They're only a band aid really though - what
> is really needed is a ground up review/redesign of the way the two
> object models are tied together as the current scheme basically
> doesn't work at all
In message <[EMAIL PROTECTED]>
Marc Munro <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-23-08 at 12:14 -0600, Charlie Savage wrote:
>
> > If not, can you install a callback into libxml to be alerted when a node
> > is freed? If so, then you could decrement the reference count. But
> > you
This is good foreign intelligence. In your searching, did you find
anything to indicate that the py interface had been changed to cope
with these issues from 2004?
Dan
On Aug 23, 2007, at 14:32, Charlie Savage wrote:
> Seems the python community has some of the same issues.
>
> http://web.ar
25 matches
Mail list logo