[PATCH,FORTRAN] Fix memory leak of gsymbol

[PATCH,FORTRAN] Fix memory leak of gsymbol

[Bernhard Reutner-Fischer]

Hi!

Regtested on x86_64-unknown-linux, installing on
aldot/fortran-fe-stringpool.

We did not free global symbols. For a simplified abstract_type_3.f03
valgrind reports:

96 bytes in 1 blocks are still reachable in loss record 461 of 602
   at 0x48377D5: calloc (vg_replace_malloc.c:711)
   by 0x21257C3: xcalloc (xmalloc.c:162)
   by 0x98611B: gfc_get_gsymbol(char const*) (symbol.c:4341)
   by 0x932C58: parse_module() (parse.c:5912)
   by 0x9336F8: gfc_parse_file() (parse.c:6236)
   by 0x991449: gfc_be_parse_file() (f95-lang.c:204)
   by 0x11D8EDE: compile_file() (toplev.c:455)
   by 0x11DB9C3: do_compile() (toplev.c:2170)
   by 0x11DBCAF: toplev::main(int, char**) (toplev.c:2305)
   by 0x2045D37: main (main.c:39)

This patch reduces leaks to

 LEAK SUMMARY:
    definitely lost: 344 bytes in 1 blocks
    indirectly lost: 3,024 bytes in 4 blocks
      possibly lost: 0 bytes in 0 blocks
-   still reachable: 1,576,174 bytes in 2,277 blocks
+   still reachable: 1,576,078 bytes in 2,276 blocks
         suppressed: 0 bytes in 0 blocks

gcc/fortran/ChangeLog:

2018-10-21  Bernhard Reutner-Fischer  <aldot@gcc.gnu.org>

	* parse.c (clean_up_modules): Free gsym.
---
 gcc/fortran/parse.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index b7265c42f58..f7c369a17ac 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -6066,7 +6066,7 @@ resolve_all_program_units (gfc_namespace *gfc_global_ns_list)
 
 
 static void
-clean_up_modules (gfc_gsymbol *gsym)
+clean_up_modules (gfc_gsymbol *&gsym)
 {
   if (gsym == NULL)
     return;
@@ -6074,14 +6074,18 @@ clean_up_modules (gfc_gsymbol *gsym)
   clean_up_modules (gsym->left);
   clean_up_modules (gsym->right);
 
-  if (gsym->type != GSYM_MODULE || !gsym->ns)
+  if (gsym->type != GSYM_MODULE)
     return;
 
-  gfc_current_ns = gsym->ns;
-  gfc_derived_types = gfc_current_ns->derived_types;
-  gfc_done_2 ();
-  gsym->ns = NULL;
-  return;
+  if (gsym->ns)
+    {
+      gfc_current_ns = gsym->ns;
+      gfc_derived_types = gfc_current_ns->derived_types;
+      gfc_done_2 ();
+      gsym->ns = NULL;
+    }
+  free (gsym);
+  gsym = NULL;
 }
 
 
-- 
2.19.1

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Bernhard Reutner-Fischer]

ping
[I'll rebase and retest this too since it's been a while.
Ok if it passes?]

On Sun, 21 Oct 2018 16:04:34 +0200
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> Hi!
> 
> Regtested on x86_64-unknown-linux, installing on
> aldot/fortran-fe-stringpool.
> 
> We did not free global symbols. For a simplified abstract_type_3.f03
> valgrind reports:
> 
> 96 bytes in 1 blocks are still reachable in loss record 461 of 602
>    at 0x48377D5: calloc (vg_replace_malloc.c:711)
>    by 0x21257C3: xcalloc (xmalloc.c:162)
>    by 0x98611B: gfc_get_gsymbol(char const*) (symbol.c:4341)
>    by 0x932C58: parse_module() (parse.c:5912)
>    by 0x9336F8: gfc_parse_file() (parse.c:6236)
>    by 0x991449: gfc_be_parse_file() (f95-lang.c:204)
>    by 0x11D8EDE: compile_file() (toplev.c:455)
>    by 0x11DB9C3: do_compile() (toplev.c:2170)
>    by 0x11DBCAF: toplev::main(int, char**) (toplev.c:2305)
>    by 0x2045D37: main (main.c:39)
> 
> This patch reduces leaks to
> 
>  LEAK SUMMARY:
>     definitely lost: 344 bytes in 1 blocks
>     indirectly lost: 3,024 bytes in 4 blocks
>       possibly lost: 0 bytes in 0 blocks
> -   still reachable: 1,576,174 bytes in 2,277 blocks
> +   still reachable: 1,576,078 bytes in 2,276 blocks
>          suppressed: 0 bytes in 0 blocks
> 
> gcc/fortran/ChangeLog:
> 
> 2018-10-21  Bernhard Reutner-Fischer  <aldot@gcc.gnu.org>
> 
> 	* parse.c (clean_up_modules): Free gsym.
> ---
>  gcc/fortran/parse.c | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index b7265c42f58..f7c369a17ac 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -6066,7 +6066,7 @@ resolve_all_program_units (gfc_namespace *gfc_global_ns_list)
>  
>  
>  static void
> -clean_up_modules (gfc_gsymbol *gsym)
> +clean_up_modules (gfc_gsymbol *&gsym)
>  {
>    if (gsym == NULL)
>      return;
> @@ -6074,14 +6074,18 @@ clean_up_modules (gfc_gsymbol *gsym)
>    clean_up_modules (gsym->left);
>    clean_up_modules (gsym->right);
>  
> -  if (gsym->type != GSYM_MODULE || !gsym->ns)
> +  if (gsym->type != GSYM_MODULE)
>      return;
>  
> -  gfc_current_ns = gsym->ns;
> -  gfc_derived_types = gfc_current_ns->derived_types;
> -  gfc_done_2 ();
> -  gsym->ns = NULL;
> -  return;
> +  if (gsym->ns)
> +    {
> +      gfc_current_ns = gsym->ns;
> +      gfc_derived_types = gfc_current_ns->derived_types;
> +      gfc_done_2 ();
> +      gsym->ns = NULL;
> +    }
> +  free (gsym);
> +  gsym = NULL;
>  }
>  
>  

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Harald Anlauf]

Hi Bernhard,

Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> ping
> [I'll rebase and retest this too since it's been a while.
> Ok if it passes?]
>
> On Sun, 21 Oct 2018 16:04:34 +0200
> Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
>
>> Hi!
>>
>> Regtested on x86_64-unknown-linux, installing on
>> aldot/fortran-fe-stringpool.
>>
>> We did not free global symbols. For a simplified abstract_type_3.f03
>> valgrind reports:
>>
>> 96 bytes in 1 blocks are still reachable in loss record 461 of 602
>>     at 0x48377D5: calloc (vg_replace_malloc.c:711)
>>     by 0x21257C3: xcalloc (xmalloc.c:162)
>>     by 0x98611B: gfc_get_gsymbol(char const*) (symbol.c:4341)
>>     by 0x932C58: parse_module() (parse.c:5912)
>>     by 0x9336F8: gfc_parse_file() (parse.c:6236)
>>     by 0x991449: gfc_be_parse_file() (f95-lang.c:204)
>>     by 0x11D8EDE: compile_file() (toplev.c:455)
>>     by 0x11DB9C3: do_compile() (toplev.c:2170)
>>     by 0x11DBCAF: toplev::main(int, char**) (toplev.c:2305)
>>     by 0x2045D37: main (main.c:39)
>>
>> This patch reduces leaks to
>>
>>   LEAK SUMMARY:
>>      definitely lost: 344 bytes in 1 blocks
>>      indirectly lost: 3,024 bytes in 4 blocks
>>        possibly lost: 0 bytes in 0 blocks
>> -   still reachable: 1,576,174 bytes in 2,277 blocks
>> +   still reachable: 1,576,078 bytes in 2,276 blocks
>>           suppressed: 0 bytes in 0 blocks
>>
>> gcc/fortran/ChangeLog:
>>
>> 2018-10-21  Bernhard Reutner-Fischer  <aldot@gcc.gnu.org>
>>
>> 	* parse.c (clean_up_modules): Free gsym.
>> ---
>>   gcc/fortran/parse.c | 18 +++++++++++-------
>>   1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
>> index b7265c42f58..f7c369a17ac 100644
>> --- a/gcc/fortran/parse.c
>> +++ b/gcc/fortran/parse.c
>> @@ -6066,7 +6066,7 @@ resolve_all_program_units (gfc_namespace *gfc_global_ns_list)
>>
>>
>>   static void
>> -clean_up_modules (gfc_gsymbol *gsym)
>> +clean_up_modules (gfc_gsymbol *&gsym)
>>   {
>>     if (gsym == NULL)
>>       return;
>> @@ -6074,14 +6074,18 @@ clean_up_modules (gfc_gsymbol *gsym)
>>     clean_up_modules (gsym->left);
>>     clean_up_modules (gsym->right);
>>
>> -  if (gsym->type != GSYM_MODULE || !gsym->ns)
>> +  if (gsym->type != GSYM_MODULE)
>>       return;
>>
>> -  gfc_current_ns = gsym->ns;
>> -  gfc_derived_types = gfc_current_ns->derived_types;
>> -  gfc_done_2 ();
>> -  gsym->ns = NULL;
>> -  return;
>> +  if (gsym->ns)
>> +    {
>> +      gfc_current_ns = gsym->ns;
>> +      gfc_derived_types = gfc_current_ns->derived_types;
>> +      gfc_done_2 ();
>> +      gsym->ns = NULL;
>> +    }
>> +  free (gsym);
>> +  gsym = NULL;

this essentially looks fine, but did you inspect the callers?

With the change to the interface (*gsym -> *&gsym), it could have
effects not visible here due to the explicit gsym = NULL.

Assuming you checked that, and if it regtests fine, then it is
OK for mainline.

Thanks for the patch!

Harald

>>   }
>>
>>
>
>

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Bernhard Reutner-Fischer]

On Thu, 28 Oct 2021 23:37:59 +0200
Harald Anlauf <anlauf@gmx.de> wrote:

> Hi Bernhard,
> 
> Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > ping
> > [I'll rebase and retest this too since it's been a while.
> > Ok if it passes?]
> >
> > On Sun, 21 Oct 2018 16:04:34 +0200
> > Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> >> gcc/fortran/ChangeLog:
> >>
> >> 2018-10-21  Bernhard Reutner-Fischer  <aldot@gcc.gnu.org>
> >>
> >> 	* parse.c (clean_up_modules): Free gsym.

> this essentially looks fine, but did you inspect the callers?
> 
> With the change to the interface (*gsym -> *&gsym), it could have
> effects not visible here due to the explicit gsym = NULL.
> 
> Assuming you checked that, and if it regtests fine, then it is
> OK for mainline.

The only caller is translate_all_program_units.
Since we free only module gsyms, even -fdump-fortran-global is
unaffected by this, fwiw.

It regtests cleanly and i will push it when the rest is approved.
Thanks!

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Bernhard Reutner-Fischer]

On Fri, 29 Oct 2021 01:23:02 +0200
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On Thu, 28 Oct 2021 23:37:59 +0200
> Harald Anlauf <anlauf@gmx.de> wrote:
> 
> > Hi Bernhard,
> > 
> > Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches:  
> > > ping
> > > [I'll rebase and retest this too since it's been a while.
> > > Ok if it passes?]
> > >
> > > On Sun, 21 Oct 2018 16:04:34 +0200
> > > Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:  
> 
> > >> gcc/fortran/ChangeLog:
> > >>
> > >> 2018-10-21  Bernhard Reutner-Fischer  <aldot@gcc.gnu.org>
> > >>
> > >> 	* parse.c (clean_up_modules): Free gsym.  
> 
> > this essentially looks fine, but did you inspect the callers?
> > 
> > With the change to the interface (*gsym -> *&gsym), it could have
> > effects not visible here due to the explicit gsym = NULL.
> > 
> > Assuming you checked that, and if it regtests fine, then it is
> > OK for mainline.  
> 
> The only caller is translate_all_program_units.
> Since we free only module gsyms, even -fdump-fortran-global is
> unaffected by this, fwiw.
> 
> It regtests cleanly and i will push it when the rest is approved.
> Thanks!

Pushed as r12-4804
thanks,

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Bernhard Reutner-Fischer]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

> > The only caller is translate_all_program_units.
> > Since we free only module gsyms, even -fdump-fortran-global is
> > unaffected by this, fwiw.

AFAICS we do not have a test for -fdump-fortran-global
Do we want to add one, would the attached be OK?

thanks,

[-- Attachment #2: 0001-Fortran-add-testcase.patch --]
[-- Type: text/x-patch, Size: 1418 bytes --]

From 7e7856cf9ec88ab7fb48e7c73f9cc6495a4a9c22 Mon Sep 17 00:00:00 2001
From: Bernhard Reutner-Fischer <aldot@gcc.gnu.org>
Date: Sat, 30 Oct 2021 23:43:12 +0200
Subject: [PATCH] Fortran: add testcase

gcc/testsuite/ChangeLog:
2021-10-30  Bernhard Reutner-Fischer  <aldot@gcc.gnu.org>

	* gfortran.dg/dump-fortran-global-1.f90: New test.
---
 .../gfortran.dg/dump-fortran-global-1.f90     | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/dump-fortran-global-1.f90

diff --git a/gcc/testsuite/gfortran.dg/dump-fortran-global-1.f90 b/gcc/testsuite/gfortran.dg/dump-fortran-global-1.f90
new file mode 100644
index 00000000000..a8a1b15cce3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dump-fortran-global-1.f90
@@ -0,0 +1,25 @@
+! { dg-do compile }
+! { dg-options "-fdump-fortran-global" }
+!
+! Test that -fdump-fortran-global works
+
+integer function myifun ()
+  myifun = 42
+end function myifun
+
+program testprogram
+  implicit none
+  interface
+    subroutine sub1()
+    end subroutine sub1
+  end interface
+  integer :: myifun
+  integer :: myint1 = 42
+  real :: myreal1 = .0815
+  if (myreal1 > 1.0) stop 1
+  if (myint1 < 1) stop 2
+  if (myint1 /= myifun()) stop 3
+end program testprogram
+! { dg-output "\[\n\r]*name=myifun, sym_name=myifun\[\n\r]" }
+! { dg-output "\[\n\r]*name=testprogram\[\n\r]" }
+! { dg-prune-output "\[\n\r]*" }
-- 
2.33.0

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Harald Anlauf]

Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:
>>> The only caller is translate_all_program_units.
>>> Since we free only module gsyms, even -fdump-fortran-global is
>>> unaffected by this, fwiw.
> 
> AFAICS we do not have a test for -fdump-fortran-global
> Do we want to add one, would the attached be OK?

This doesn't seem to test anything new or changed, or a bug fixed.
I get the same result for all version from 9 to 12-mainline.
So as is it seems pointless.

> thanks,
> 

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Harald Anlauf]

Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:
>>> The only caller is translate_all_program_units.
>>> Since we free only module gsyms, even -fdump-fortran-global is
>>> unaffected by this, fwiw.
>
> AFAICS we do not have a test for -fdump-fortran-global
> Do we want to add one, would the attached be OK?

This doesn't seem to test anything new or changed, or a bug fixed.
I get the same result for all version from 9 to 12-mainline.
So as is it seems pointless.

> thanks,
>

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

[Bernhard Reutner-Fischer]

On Sun, 31 Oct 2021 20:46:07 +0100
Harald Anlauf <anlauf@gmx.de> wrote:

> Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:
> >>> The only caller is translate_all_program_units.
> >>> Since we free only module gsyms, even -fdump-fortran-global is
> >>> unaffected by this, fwiw.  
> >
> > AFAICS we do not have a test for -fdump-fortran-global
> > Do we want to add one, would the attached be OK?  
> 
> This doesn't seem to test anything new or changed, or a bug fixed.
> I get the same result for all version from 9 to 12-mainline.
> So as is it seems pointless.

Yes indeed, it just adds coverage to that functionality which we did not
exercise before.
TBH i only found that option when looking around
translate_all_program_units. I've never actually used that option
myself and cannot imagine how it is useful at all :)

Dropped the testcase.
Thanks for your comment!

cheers,

drop -fdump-fortran-global ? [was: Re: [PATCH,FORTRAN] Fix memory leak of gsymbol]

[Bernhard Reutner-Fischer]

On Sun, 31 Oct 2021 21:25:44 +0100
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On Sun, 31 Oct 2021 20:46:07 +0100
> Harald Anlauf <anlauf@gmx.de> wrote:
> 
> > Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:  
> > >>> The only caller is translate_all_program_units.
> > >>> Since we free only module gsyms, even -fdump-fortran-global is
> > >>> unaffected by this, fwiw.    
> > >
> > > AFAICS we do not have a test for -fdump-fortran-global
> > > Do we want to add one, would the attached be OK?    
> > 
> > This doesn't seem to test anything new or changed, or a bug fixed.
> > I get the same result for all version from 9 to 12-mainline.
> > So as is it seems pointless.  
> 
> Yes indeed, it just adds coverage to that functionality which we did not
> exercise before.
> TBH i only found that option when looking around
> translate_all_program_units. I've never actually used that option
> myself and cannot imagine how it is useful at all :)
> 
> Dropped the testcase.
> Thanks for your comment!

The rest of 5c6aa9a8919cbf0dcf3c375f51012720bfb5f3a1 is fine, but
should we really keep the option, if we don't even test basics and if it
was more a specific debug dump, from the looks?

Thomas?

thanks,

Re: drop -fdump-fortran-global ? [was: Re: [PATCH,FORTRAN] Fix memory leak of gsymbol]

[Thomas König]

On 25.02.23 22:55, Bernhard Reutner-Fischer wrote:
> but
> should we really keep the option, if we don't even test basics and if it
> was more a specific debug dump, from the looks?

It is always possible to add test cases if testing is required,
but I don't think this is necessary.  We also do not have test
cases for -fdump-fortran-original, which is also quite handy
and which can find a lot of bugs.

And yes, it is rather useful when debugging issues with global
identifiers, which are a bit special in Fortran.  As I wrote in
my mail when submitting the patch,

 > While debugging it, I also put in an option to dump the global
 > symbol table to standard output.  I have included this in this
 > patch because I think this may not be the last bug in that
 > area 😄

That hasn't changed, IMHO.

Best regards

	Thomas