[Fwd: Re: [Patch, Fortran] PR fotran/35820 again: memory leak while resolving nested foralls.]

[Mikael Morin <mikael dot morin at tele2 dot fr>]

Hello all,

a reminder for this patch.
I got my counter-signed copyright assignment yesterday.
I have not commit right yet, so feel free to commit for me.
Otherwise, I can do it myself as soon as I'm allowed to (but I think we
are a bit in a hurry, right?).

Cheers,
Mikael

--- Begin Message ---

• From: Mikael Morin <mikael dot morin at tele2 dot fr>
• To: Dominique Dhumieres <dominiq at lps dot ens dot fr>
• Cc: fortran at gcc dot gnu dot org
• Date: Thu, 23 Oct 2008 16:01:08 +0200
• Subject: Re: [Patch, Fortran] PR fotran/35820 again: memory leak while resolving nested foralls.
• References: <20081022211126.110703BAB9@mailhost.lps.ens.fr>

Dominique Dhumieres wrote:
>> For Dominique, one can add this to make a memory leak results in an ICE:
> 
> The three codes associated to this pr give an ICE with the patchlet
> without any other patch. All the ICEs disappear with the first patch
You should still have an ICE on nested_forall_1.f

I tested the first patch again with valgrind --leak-check=full and I get
this:

==9301== 416 (216 direct, 200 indirect) bytes in 6 blocks are definitely
lost in loss record 5 of 10
==9301==    at 0x4C259BE: malloc (vg_replace_malloc.c:207)
==9301==    by 0xB87E47: xmalloc (xmalloc.c:147)
==9301==    by 0x450F64: gfc_getmem (misc.c:37)
==9301==    by 0x471636: gfc_resolve_forall (resolve.c:6272)
==9301==    by 0x47253C: resolve_code (resolve.c:6550)
==9301==    by 0x473030: resolve_codes (resolve.c:10318)
==9301==    by 0x472FEF: resolve_codes (resolve.c:10310)
==9301==    by 0x473074: gfc_resolve (resolve.c:10337)
==9301==    by 0x460E7F: gfc_parse_file (parse.c:3837)
==9301==    by 0x49049C: gfc_be_parse_file (f95-lang.c:236)
==9301==    by 0x7204F6: toplev_main (toplev.c:968)
==9301==    by 0x52CC145: (below main) (in /lib/libc-2.7.so)

I don't understand what's going on here.
My second patch was supposed to solve memory chunks being freed too early.
But these errors show that the memory pointers are overwritten, not that
we are using an already freed memory zone.
It seems that the memory is not freed as I thought.
Is gcc using its own builtin malloc/free ?

This error is not shown with the second patch, so maybe we shouldn't
bother.

I attach the updated patch with Paul's suggestions:
static declaration and final module cleanup for the test.

Thanks for your comments and testings.
Mikael.

PS: Valgrind shows some errors left, maybe I should file a bug for these.

Attachment: pr35820_3.changes
Description: Text document

Attachment: pr35820_90.diff
Description: Text document

--- End Message ---