Hello,
I have a strange memory leak in my XML parser which I cannot locate
using valgrind.
In my testcase I'm creating and deleting a XML node and after the test
valgrind is not showing any memory leaks but rss memory is still
active VmRSS: 11184 kB ( VmRSS after the XML node creation was
One thing that might be relevant is that errors already have a
32 bit value that identifies them uniquely. struct _Error :: unique
You can see them in the XML output, eg
./vg-in-place --xml=yes --xml-fd=1 memcheck/tests/errs1
I would prefer to use them, rather than add yet another kind of
I am an interested bystander. Last year I diagnosed a 2+ year long storage
growth issue where there was no storage leak... firmly proven.
The diagnosis was a case of extreme fragmentation. The process needed large
chunks of contiguous storage [2-3 megs] and when released the system
storage
John Alvord wrote:
I am an interested bystander. Last year I diagnosed a 2+ year long storage
growth issue where there was no storage leak... firmly proven.
The diagnosis was a case of extreme fragmentation. The process needed large
chunks of contiguous storage [2-3 megs] and when released
Hmm, this doesn't sound like it's going to be simple to fix in
a clean way.
For the moment, can we do the incremental fix of taking Philippe's
patch (with the off-by-one fixed) ? That's a very simple patch
and uncontroversial patch. (Maybe should also backport it for
3.7.1 ?)
J
On Tuesday,
On Tue, 2012-02-14 at 13:54 +, Rob wrote:
One thing that might be relevant is that errors already have a
32 bit value that identifies them uniquely. struct _Error :: unique
You can see them in the XML output, eg
./vg-in-place --xml=yes --xml-fd=1 memcheck/tests/errs1
I would
Hmm, this doesn't sound like it's going to be simple to fix in
a clean way.
For the moment, can we do the incremental fix of taking Philippe's
patch (with the off-by-one fixed) ? That's a very simple patch
and uncontroversial patch. (Maybe should also backport it for
3.7.1 ?)
Sounds good
On Tue, 2012-02-14 at 23:52 +0100, Julian Seward wrote:
Hmm, this doesn't sound like it's going to be simple to fix in
a clean way.
For the moment, can we do the incremental fix of taking Philippe's
patch (with the off-by-one fixed) ? That's a very simple patch
and uncontroversial patch.
On 2/14/2012 6:12 PM, Julian Seward wrote:
So ... I am running tests with the decoder revised to allow 0x66 on the fpu
instructions.
Does anyone know of a reason why doing this would be bad/wrong?
Giving a blanket OK for 0x66 on FPU instructions makes me nervous, that we
might
