oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.28k stars 1.63k forks source link

[GR-32291] Memory Leak on graal_isolatethread_t #3474

Open machaval opened 3 years ago

machaval commented 3 years ago

Memory Leak detected on graal_isolatethread_t

I'm trying to build a SharedLibrary that allows to execute my language runtime from other languages like i this case GO. This function is going to be called multiple times, so I did a simulation to see how it behaves, memory, cpu. And I was seeing a small memory leak. What I did was very simple First

graal_isolatethread_t* thread;
    if (graal_create_isolate(NULL, NULL, &thread)) {
      return -1;
    }

Second do my stuff

runScript("myScript")

Third

 if (graal_tear_down_isolate(thread) != 0) {
       fprintf(stderr, "shutdown error\n");
       return 1;
     }

I put it inside a while true and I started to see that the memory usage of the process was growing, slowly but constantly.

So I commented the call to my code

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <graal_isolate.h>
#include <unistd.h>
int main(int argc, char** argv) {
//  compilation_result result;
//  char* expression = "attributes.headers.myParam";
//  printf("Expression is %p\n", expression);
  while(1){
    int i = 1;
    while (i < 4)
    {
        graal_isolatethread_t* thread;
        if (graal_create_isolate(NULL, NULL, &thread)) {
           return -1;
        }

        //
        // This frees all memory allocated by the GraalVM runtime
        //
          if (graal_tear_down_isolate(thread) != 0) {
             fprintf(stderr, "shutdown error\n");
             return 1;
          }
          printf("Thread is %p\n", thread);
          thread = NULL;
          i = i + 1;
       }
      sleep(1000000);
   }

    return 0;
}

I'm just using graal libraries.

And If I compile this script using clang and using mac leaks tool it shows

leaks Report Version: 4.0
Process 98105: 515 nodes malloced for 579 KB
Process 98105: 3 leaks for 864 total leaked bytes.

    3 (864 bytes) << TOTAL >>
      1 (288 bytes) ROOT LEAK: 0x7fe83fc04080 [288]
      1 (288 bytes) ROOT LEAK: 0x7fe83fc041a0 [288]
      1 (288 bytes) ROOT LEAK: 0x7fe84fd0a190 [288]

So as it can be seen after 3 loops 3 leaks are being detected.

Describe GraalVM and your environment:

oubidar-Abderrahim commented 3 years ago

Thank you for reporting this issue, could you please provide the exact command you use to compile the above example? also, the version of clang you're using?

machaval commented 3 years ago

Hi Thanks for taking a look at the issue. I've created a project that showcase the issue. Just unzip the attached zip and inside there is a compile.sh (clang -I./src/main/c/ -L./src/main/c/ -ldw ./src/main/c/DataWeaveNative.c -o DataWeaveNative) that compiles the project.
native-leak.zip

Then what I do is executes leaks DataWeaveNative in another terminal while this process is running and it shows the leaks.

My current version of clang is

➜  native-leak clang --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
machaval commented 3 years ago

@oubidar-Abderrahim Is this information good enough? Do you need more data to reproduce the issue?

oubidar-Abderrahim commented 3 years ago

Yes, I managed to reproduce the issue, thank you for the reproducer. This issue is tracked internally on GR-32291

blacktooth commented 2 years ago

Is this issue fixed?

peter-hofer commented 2 years ago

Unfortunately, this is not a single bug, but a number of issues mostly caused by native code of the JDK assuming that there is only ever going to be one isolate, so this is ongoing work.