Hey Aaron,
Looks like the xmlOutputBufferPtr never gets freed.
Yup, exactly right. I posted a fix to trunk and sent another email to
the list, but somehow it never made it through.
Index: ext/libxml/ruby_xml_node.c
===
--- ex
2009/1/7 Charlie Savage :
> Hi Joseph,
>
>>> I'll see if I can put something together, we know it's in the
>>> to_solr_doc from acts_as_solr somewhere.
>>
>> Looks like the problem is in to_s on Node
>>
>> 1.times do
>> node = XML::Node.new 'node'
>> node.to_s
>> end
>
> Nice work - that's a
On Jan 7, 4:06 pm, Charlie Savage wrote:
> Hi Joseph,
>
> >> I'll see if I can put something together, we know it's in the
> >> to_solr_doc from acts_as_solr somewhere.
>
> > Looks like the problem is in to_s on Node
>
> > 1.times do
> > node = XML::Node.new 'node'
> > node.to_s
> > end
Looks like the problem is in to_s on Node
1.times do
node = XML::Node.new 'node'
node.to_s
end
Anyway, will have to look and see if there is anything obvious in the
part of the bindings.
And fixed in trunk. It was caused by the addition of encoding support
in the last couple of
Hi Joseph,
I'll see if I can put something together, we know it's in the
to_solr_doc from acts_as_solr somewhere.
Looks like the problem is in to_s on Node
1.times do
node = XML::Node.new 'node'
node.to_s
end
Nice work - that's a great test case.
So if I I run this code:
1000.
On Jan 7, 1:38 pm, Joseph Palermo wrote:
> On Jan 7, 1:08 pm, Charlie Savage wrote:
>
>
>
> > Hi Joseph,
>
> > > We are using some code that utilizes libxml and creates XML
> > > documents. Using 0.9.5 everything is fine. Using 0.9.6 or 0.9.7, the
> > > more we use this code, the higher our m
On Jan 7, 1:08 pm, Charlie Savage wrote:
> Hi Joseph,
>
> > We are using some code that utilizes libxml and creates XML
> > documents. Using 0.9.5 everything is fine. Using 0.9.6 or 0.9.7, the
> > more we use this code, the higher our memory usage gets.
>
> > Seems likely that a memory leak wa
Hi Joseph,
We are using some code that utilizes libxml and creates XML
documents. Using 0.9.5 everything is fine. Using 0.9.6 or 0.9.7, the
more we use this code, the higher our memory usage gets.
Seems likely that a memory leak was introduced in 0.9.6. We are
seeing this same behavior on O
We are using some code that utilizes libxml and creates XML
documents. Using 0.9.5 everything is fine. Using 0.9.6 or 0.9.7, the
more we use this code, the higher our memory usage gets.
Seems likely that a memory leak was introduced in 0.9.6. We are
seeing this same behavior on OS X and Gentoo.
That version has all of the really bad leaks taken care of. There is a
more recent version in SVN, but it is not in an RC state, which may be
a few more days. It has a few more fixes, including some to XPath.
I'll announce the update, hopefully soon.
Dan
On Dec 18, 2007, at 08:49, [EMAIL PRO
I am running version 0.5.2.0.
Simon
Depends on the version you are running.
ruby -e 'require "xml/libxml"; puts XML::Parser::VERSION'
On Dec 17, 2007, at 18:47, [EMAIL PROTECTED] wrote:
> Hi,
>
> I have an application that reads a listing of files from a
> directory, and then uses libxml-rub
Depends on the version you are running.
ruby -e 'require "xml/libxml"; puts XML::Parser::VERSION'
On Dec 17, 2007, at 18:47, [EMAIL PROTECTED] wrote:
> Hi,
>
> I have an application that reads a listing of files from a
> directory, and then uses libxml-ruby (using XPath) to parse the
> files
Hi,
I have an application that reads a listing of files from a directory, and then
uses libxml-ruby (using XPath) to parse the files. This occurs in a loop,
picking up new files as they are added. Over time, memory really grows on the
process doing this work. Are there any known memory issue
Adding a node that is not part of a document as a child of a node that
is part of a document leaks a copy of the node.
The problem is ruby_xml_node_child_set() will copy the node being added
as a child into the document of it's new parent, and then changes its
second argument to refer to that copy
14 matches
Mail list logo
