https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110063

            Bug ID: 110063
           Summary: Leaks in gcc driver accumulate when calling
                    gcc_jit_context_compile
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: jit
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: eliaz.pitavy at obspm dot fr
  Target Milestone: ---

Created attachment 55224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55224&action=edit
Full output of ASan with -fsanitize=address

Local build of gcc 13.1.0
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.1.0/configure --prefix=/home/epitavy/.local/
--disable-multilib --enable-host-shared --enable-languages=all

The following code is compiled with these options:
g++ --std=c++2a -fsanitize=address -I ~/.local leak.cc -lgccjit -L ~/.local -o
leak

The content of the file (leak.cc):
#include <libgccjit++.h>

int main(){
    gccjit::context ctx = gccjit::context::acquire();
    gcc_jit_result *result;

    for (int i = 0; i < 100; i++) {
        result = ctx.compile();
        gcc_jit_result_release(result);
    }

    ctx.release();
}


Here a truncated ASan report, the full report is in attachment:
SUMMARY: AddressSanitizer: 855270 byte(s) leaked in 5886 allocation(s)
   xmalloc ../../gcc-13.1.0/libiberty/xmalloc.c:149
   make_temp_file_with_prefix ../../gcc-13.1.0/libiberty/make-temp-file.c:213
   ...
   handle_braces ../../gcc-13.1.0/gcc/gcc.cc:7252
   do_spec_1 ../../gcc-13.1.0/gcc/gcc.cc:6659
   do_spec_2 ../../gcc-13.1.0/gcc/gcc.cc:5713
   do_spec(char const*) ../../gcc-13.1.0/gcc/gcc.cc:5677
   driver::do_spec_on_infiles() const ../../gcc-13.1.0/gcc/gcc.cc:8903
   driver::main(int, char**) ../../gcc-13.1.0/gcc/gcc.cc:8131

When using gcc as a standalone program, the memory leaks of the driver are not
important, but when integrated into a program with jit compilation, each
compilation triggers new memory leaks, independently of the user code.

The leak is not related directly with libgccjit but matters for its use case.

Reply via email to