Project

Profile

Help

Possible memory leak in SchemaValidator class

Added by Paul Greve 9 months ago

We're using Saxonc-eec-12.2 for the ARMv8 on linux to do schema validation of XML source docs. There appears to be a memory leak in the SchemaValidator class, more specfically when calling the registerSchemaFromFile function.

Attached is a sample program for the x86 that demonstrates the leak. It calls SaxonProcessor::newSchemaValidator() to create a SchemaValidator and then calls delete on the SchemaValidator after doing the validation.

Should we be calling something in addition to delete to release the memory used by the SchemaValidator?


Replies (6)

Please register to reply

RE: Possible memory leak in SchemaValidator class - Added by O'Neil Delpratt 9 months ago

Thanks for reporting the issue you found.

I will take a closer look and run the code you have supplied. But just on first observation is the SaxonApiException always thrown or is there some iteration of the loop?

One thing to mention is the node object is not deleted at the end of the loop. The SchemaValidator will not delete the node even though you have called validator->setSourceNode(node).

RE: Possible memory leak in SchemaValidator class - Added by O'Neil Delpratt 9 months ago

I managed to run the repo using valgrind with iteration=2. See the leak summary:

==158361== LEAK SUMMARY:
==158361==    definitely lost: 350 bytes in 3 blocks
==158361==    indirectly lost: 0 bytes in 0 blocks
==158361==      possibly lost: 288 bytes in 1 blocks
==158361==    still reachable: 49,504 bytes in 3 blocks
==158361==         suppressed: 0 bytes in 0 blocks
==158361== Rerun with --leak-check=full to see details of leaked memory

If I delete the node object add at the end of the try block. i.e.:

delete node;
node = nullptr;

And rerun valgrind the leak summary looks better. As mention before this causes a memory leak if you don't delete it. See the valgrind report:

==158508== LEAK SUMMARY:
==158508==    definitely lost: 14 bytes in 1 blocks
==158508==    indirectly lost: 0 bytes in 0 blocks
==158508==      possibly lost: 288 bytes in 1 blocks
==158508==    still reachable: 49,504 bytes in 3 blocks
==158508==         suppressed: 0 bytes in 0 blocks

I will investigate where the 14 bytes are lost. I guess it might be some string not being cleared.

For the 288 bytes possibly lost it might be constant, but is not so clear to me the cause. Looking at the valgrind full check it looks like something transient in the threads:

==158512== 288 bytes in 1 blocks are possibly lost in loss record 3 of 5
==158512==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==158512==    by 0x40147D9: calloc (rtld-malloc.h:44)
==158512==    by 0x40147D9: allocate_dtv (dl-tls.c:375)
==158512==    by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==158512==    by 0xA2F6834: allocate_stack (allocatestack.c:430)
==158512==    by 0xA2F6834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==158512==    by 0x4EF3913: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158512==    by 0xCA40717: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158512==    by 0xFFFFFFEFFFFF: ???
==158512==    by 0xCEF8C17: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158512==    by 0xCA4B1C7: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158512==    by 0xFFFFFFFFFFFE: ???
==158512==    by 0x4EF3900: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158512==    by 0x1FFEFFFBCF: ???

RE: Possible memory leak in SchemaValidator class - Added by O'Neil Delpratt 9 months ago

Running valgrind with options --leak-check=full --show-leak-kinds=all gives some clue where the 14 bytes are lost:

==158520== 14 bytes in 1 blocks are definitely lost in loss record 1 of 5
==158520==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==158520==    by 0xA30960E: strdup (strdup.c:42)
==158520==    by 0x6D226C7: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0x6D22755: findJavaTZ_md (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0x5A3B65E: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0xCC7B2AF: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0x4EEB4DC: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0xE9ECD3F: ???
==158520==    by 0x4EEBE0E: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0xCC7B2AF: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0x4EEBFE4: ??? (in /usr/lib/libsaxon-eec-12.3.so)
==158520==    by 0xC1CA30F: ??? (in /usr/lib/libsaxon-eec-12.3.so)

Not sure the caused yet, maybe this is deep in Graalvm.

RE: Possible memory leak in SchemaValidator class - Added by Paul Greve 9 months ago

Hi O'Neil,

Thanks for responding so quickly. In regards to the SaxonAPIException, it is not being thrown. I had also noticed that the node object was not being deleted prior to posting; but it was unclear as to whether or not it needed to be deleted as it's not being deleted in the testValidator sample provided with the API.

We're actually running out of memory on our target system. I have a higher priority issue to work this morning; but I'll make the change to delete the node object on our target system as soon as I have a chance and let you know how that goes.

Paul

RE: Possible memory leak in SchemaValidator class - Added by O'Neil Delpratt 9 months ago

Thanks for the observation of the node object in the sample program. I will fix the samples accordingly that don't have a delete. Apologies if this caused a confusion. I have created the bug issue #6195 to track its progress.

RE: Possible memory leak in SchemaValidator class - Added by Paul Greve 9 months ago

Hi O'Neil,

I made the change to delete the node object on our target system and it looks like that fixed our memory leak. Thanks for you help in finding this.

Paul

    (1-6/6)

    Please register to reply