Saxon » SaxonC

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).

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: ???

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.

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

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.

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