Saxon » SaxonC

Hi Paul,

Thanks for reporting this issue. I have reproduced what valgrind reports. I am currently investigating it and will report back shortly.

Thanks O'Neil

In the latest unreleased dev code on SaxonC 12 I am seeing the following:

==567279== LEAK SUMMARY:
==567279==    definitely lost: 14 bytes in 1 blocks
==567279==    indirectly lost: 0 bytes in 0 blocks
==567279==      possibly lost: 616 bytes in 2 blocks
==567279==    still reachable: 49,176 bytes in 2 blocks
==567279==         suppressed: 0 bytes in 0 blocks

I think the 14 bytes on my code base is lost where we create the. XsltExecutable:

xslt = xsltProcessor->compileFromString(styleSheet);

Still not sure why, but narrowing it down.

Hi Paul,

This looks like a duplicate of the discussion here: https://saxonica.plan.io/boards/4/topics/9525

Hi O'Neill,

This case is a little different than my prior post. As you correctly pointed out before, I was not deleting the XdmNode returned by the document parse. Currently, we've added the use of XSLT. Also, I believe I'm now correctly deleting everything allocated from calls to the API but still experiencing leaks. I went back and ran a simple 'validation only' scenario with valgrind (attached) and it reports 0 bytes definitely lost and 288 bytes possibly lost which I assume tracks to the allocation of the SaxonProcessor.

Paul

Yes I agree the posts are different. But some how in XSLT the run is triggering the call to findJavaTZ_md which I did see in the other post. This is causing the memory leak (14 bytes). I am still investigating it, but it looks like its deep down in the Java code.

I managed to create a SaxonC debug library which has given a better trace in valgrind.

First the 288 bytes I am seeing that are possibly lost are to do with the graalvm isolate:

==3224== 288 bytes in 1 blocks are possibly lost in loss record 3 of 7
==3224==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3224==    by 0x40147D9: calloc (rtld-malloc.h:44)
==3224==    by 0x40147D9: allocate_dtv (dl-tls.c:375)
==3224==    by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==3224==    by 0xAB7A7B4: allocate_stack (allocatestack.c:430)
==3224==    by 0xAB7A7B4: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==3224==    by 0x4EE0FE4: ??? (Pthread.java:0)
==3224==    by 0x4EE5370: ??? (PosixPlatformThreads.java:116)
==3224==    by 0x4EFC7A2: ??? (PlatformThreads.java:738)
==3224==    by 0x56D2207: ??? (Target_java_lang_Thread.java:386)
==3224==    by 0x56D202D: ??? (Thread.java:798)
==3224==    by 0x4E9C378: ??? (CEntryPointSnippets.java:292)
==3224==    by 0x4E2D70F: ??? (CEntryPointNativeFunctions.java:80)
==3224==    by 0x4E497E4: graal_create_isolate (IsolateEnterStub.java:1)
==3224==    by 0x10FDF5: create_graalvm_isolate (SaxonCGlue.c:33)

This is only created once and is killed at the end of the problem. I think we can live with it.

In regards to the 14 bytes lost we have the following:

==3224== 14 bytes in 1 blocks are definitely lost in loss record 1 of 7
==3224==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3224==    by 0xAB8D58E: strdup (strdup.c:42)
==3224==    by 0x6A7A057: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==3224==    by 0x6A7A0E5: findJavaTZ_md (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==3224==    by 0x4E217A4: ??? (LibCHelper.java:0)
==3224==    by 0x590C209: ??? (TimeZoneSubstitutions.java:96)
==3224==    by 0x590CAB1: ??? (TimeZone.java:671)
==3224==    by 0x590BCE2: ??? (TimeZone.java:653)
==3224==    by 0x590BC54: ??? (TimeZone.java:642)
==3224==    by 0x5815C94: ??? (ZoneId.java:272)
==3224==    by 0x58098F4: ??? (Clock.java:184)
==3224==    by 0x5819224: ??? (ZonedDateTime.java:199)

I am still investigating this, but in the Saxon code we do use ZonedDateTime in various places.

Hi O'Neil.

One question regarding the loss from the graalvm isolate. Does that loss occur each time a new SaxonProcessor is created? Such that we would want to make our SaxonProcessor a singleton and re-use it for each document parse/validation/transformation?

Paul

Paul Greve wrote in RE: Possible memory leaks:

Hi O'Neil.

One question regarding the loss from the graalvm isolate. Does that loss occur each time a new SaxonProcessor is created? Such that we would want to make our SaxonProcessor a singleton and re-use it for each document parse/validation/transformation?

No. The graalvm isolate is created only once. I created several SaxonProcessor object and not seeing any difference. I am not sure if we would see would see the same effect if we create multiple SaxonProcessors under multiple threads.

OK. Thanks. Good to know.

With some help from valgrind options. The stack trace where things are going wrong in findJavaTZ_md is below:

==4403== 14 bytes in 1 blocks are definitely lost in loss record 1 of 6
==4403==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4403==    by 0xAB8D58E: strdup (strdup.c:42)
==4403==    by 0x6A7A057: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==4403==    by 0x6A7A0E5: findJavaTZ_md (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==4403==    by 0x4E217A4: ??? (LibCHelper.java:0)
==4403==    by 0x590C209: ??? (TimeZoneSubstitutions.java:96)
==4403==    by 0x590CAB1: ??? (TimeZone.java:671)
==4403==    by 0x590BCE2: ??? (TimeZone.java:653)
==4403==    by 0x590BC54: ??? (TimeZone.java:642)
==4403==    by 0x5815C94: ??? (ZoneId.java:272)
==4403==    by 0x58098F4: ??? (Clock.java:184)
==4403==    by 0x5819224: ??? (ZonedDateTime.java:199)
==4403==    by 0x64EAD54: ??? (DateTimeValue.java:156)
==4403==    by 0x62C36CF: ??? (UseWhenFilter.java:66)
==4403==    by 0x62B5CBD: ??? (StylesheetModule.java:206)
==4403==    by 0x626ED28: ??? (Compilation.java:115)
==4403==    by 0x61F5DD2: ??? (XsltCompiler.java:971)
==4403==    by 0x60E622D: ??? (Xslt30Processor.java:550)
==4403==    by 0x4E60FB3: j_compileFromString (IsolateEnterStub.java:1)
==4403==    by 0x11E661: Xslt30Processor::compileFromString(char const*, char const*) (Xslt30Processor.cpp:330)

In SaxonC 12.5 we are using Graalvm 22.3.1. I am still investigating if the bug is in their code.

I tried building SaxonC 12.X against GraalVM for JDK 21 Community 21.0.2, which is essentially version 23.1.6 and the memory leak has gone away. See report from valgrind:

==15940== HEAP SUMMARY:
==15940==     in use at exit: 1,141 bytes in 6 blocks
==15940==   total heap usage: 70 allocs, 64 frees, 138,577 bytes allocated
==15940== 
==15940== 288 bytes in 1 blocks are possibly lost in loss record 4 of 6
==15940==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==15940==    by 0x40147D9: calloc (rtld-malloc.h:44)
==15940==    by 0x40147D9: allocate_dtv (dl-tls.c:375)
==15940==    by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==15940==    by 0xBC107B4: allocate_stack (allocatestack.c:430)
==15940==    by 0xBC107B4: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==15940==    by 0x4FCAEA2: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==15940==    by 0x5C8A9EAF: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==15940==    by 0x4F2C8F0: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==15940==    by 0x54552AFEFFFBCF: ???
==15940==    by 0x5C72A94F: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==15940==    by 0x5CAC1577: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==15940==    by 0x4FCAE8D: ??? (in /home/ond1/work/repository/saxondev-12/build/releases/libsaxon-EEC-linux-amd64-v12.5.0/libs/nix/libsaxon-eec-12.5.0.so)
==15940==    by 0x1FFEFFFB8F: ???
==15940== 
==15940== LEAK SUMMARY:
==15940==    definitely lost: 0 bytes in 0 blocks
==15940==    indirectly lost: 0 bytes in 0 blocks
==15940==      possibly lost: 288 bytes in 1 blocks
==15940==    still reachable: 853 bytes in 5 blocks
==15940==         suppressed: 0 bytes in 0 blocks

Now creating a bug issue to keep track of this problem.

So then the leak is in either in GraalVM or the JVM that GraalVM is using. What's the time frame for a fix or is there a workaround?

Paul

This is a bug against Graalvm version 22.3.1. Bug issue created: #6672