Calling the driver::finalize() method before returning from main
seems to be reducing some memory leaks of the driver (PR93019).

$ head -n20 before_patch.txt
==385521== Memcheck, a memory error detector
==385521== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==385521== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright
info
==385521== Command: /home/cargyris/gcc/install/bin/gcc -g -O2 t1.c
==385521== Parent PID: 165153
==385521==
==385521==
==385521== HEAP SUMMARY:
==385521==     in use at exit: 173,136 bytes in 115 blocks
==385521==   total heap usage: 497 allocs, 382 frees, 229,696 bytes
allocated
==385521==
==385521== 1 bytes in 1 blocks are still reachable in loss record 1 of 99

$ head -n20 after_patch.txt
==397575== Memcheck, a memory error detector
==397575== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==397575== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright
info
==397575== Command: /home/cargyris/gcc/install/bin/gcc -g -O2 t1.c
==397575== Parent PID: 165153
==397575==
==397575==
==397575== HEAP SUMMARY:
==397575==     in use at exit: 146,573 bytes in 77 blocks
==397575==   total heap usage: 497 allocs, 420 frees, 229,696 bytes
allocated
==397575==
==397575== 3 bytes in 1 blocks are indirectly lost in loss record 1 of 61

This makes some sense because driver::finalize() performs many
memory deallocations, among other things.    It was introduced here:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9376dd63e6a2d94823f6faf8212c9f37bef5a656

Is there any reason for not wanting to call it before returning from main?

Also, the driver constructor's can_finalize boolean looks more like a
can_restore_env boolean, as it only affects the environment manager
and nothing else in the driver (no?).    By making driver::finalize() call
env.restore() conditional on can_restore_env, it is possible to always
call driver::finalize() even for can_restore_env == false and still do all
the rest that finalize() does, including freeing memory.

Is there anything wrong with calling d.finalize() from main without
restoring the environment?    The next step is returning from main
anyway, and the program ends, so I can't think of any reason not
to do this, given that it helps with the memory leaks.    Is there?

Attachment: 0001-driver-Call-finalize-method-from-main.patch
Description: Binary data

Reply via email to