[Bug fortran/108109] New: [ICE] gfortran compilation fails calling 'free()' with 'malloc(): mismatching next->prev_size (unsorted)'

[Bug fortran/108109] New: [ICE] gfortran compilation fails calling 'free()' with 'malloc(): mismatching next->prev_size (unsorted)'

[burnus at gcc dot gnu.org]

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

            Bug ID: 108109
           Summary: [ICE] gfortran compilation fails calling 'free()' with
                    'malloc(): mismatching next->prev_size (unsorted)'
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54092&action=edit
Testcase - compile with 'gfortran test.f90'

Fails with GCC 13, 12 and 11.


Found when looking at https://github.com/olcf/openmp-gpu-library , namely the
MatrixMultiply_OpenMP_HIP_ROCm/MM_GPU_Library_Module.f90 example.

Lacking some modules, it fails to compile (expected) but during error recovery,
it seems as if the memory is somehow corrupting, crashing GCC as follows
without a backtrace:

corrupted size vs. prev_size
corrupted size vs. prev_size
gfortran: internal compiler error: Aborted signal terminated program f951

The slightly reduced attached testcase fails likewise.

 * * *

There is no backtrace, but running it in gdb shows:

#1  0x00007ffff77b0859 in __GI_abort () at abort.c:79
#2  0x00007ffff781b26e in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7ffff7945298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff78232fc in malloc_printerr (str=str@entry=0x7ffff7947aa0
"malloc(): mismatching next->prev_size (unsorted)") at malloc.c:5347
#4  0x00007ffff782635c in _int_malloc (av=av@entry=0x7ffff797ab80 <main_arena>,
bytes=bytes@entry=2792) at malloc.c:3741
#5  0x00007ffff7829b95 in __libc_calloc (n=<optimized out>,
elem_size=<optimized out>) at malloc.c:3428
#6  0x0000000002006b35 in xcalloc (nelem=1, elsize=2792) at
../../repos/gcc-trunk-commit/libiberty/xmalloc.c:164
#7  0x000000000097efaf in gfc_get_namespace (parent=parent@entry=0x2d069d0,
parent_types=parent_types@entry=0)
    at ../../repos/gcc-trunk-commit/gcc/fortran/symbol.cc:2869
#8  0x0000000000981df6 in gfc_copy_formal_args_intr (dest=dest@entry=0x2d1eb60,
src=src@entry=0x7ffff6f9ec90, actual=actual@entry=0x0, 
    copy_type=copy_type@entry=false) at
../../repos/gcc-trunk-commit/gcc/fortran/symbol.cc:4683
#9  0x000000000094c128 in gfc_resolve_intrinsic (sym=sym@entry=0x2d1eb60,
loc=loc@entry=0x2d1eb70)
    at ../../repos/gcc-trunk-commit/gcc/fortran/resolve.cc:1887
#10 0x000000000094d94c in resolve_symbol (sym=<error reading variable:
dwarf2_find_location_expression: Corrupted DWARF expression.>)
    at ../../repos/gcc-trunk-commit/gcc/fortran/resolve.cc:15788
#11 0x0000000000978853 in do_traverse_symtree (st=<optimized out>, st_func=0x0,
sym_func=0x94cd70 <resolve_symbol(gfc_symbol*)>)
    at ../../repos/gcc-trunk-commit/gcc/fortran/symbol.cc:4186
#12 0x0000000000958b1f in resolve_types (ns=0x2d069d0) at
../../repos/gcc-trunk-commit/gcc/fortran/resolve.cc:17551
#13 0x000000000095f6ed in gfc_resolve (ns=0x2d069d0) at
../../repos/gcc-trunk-commit/gcc/fortran/resolve.cc:17666
#14 0x000000000094cd5e in gfc_resolve (ns=<optimized out>) at
../../repos/gcc-trunk-commit/gcc/fortran/resolve.cc:17653

 * * *

The call looks harmless:


#6  0x0000000002006b35 in xcalloc (nelem=1, elsize=2792) at
../../repos/gcc-trunk-commit/libiberty/xmalloc.c:164
164       newmem = calloc (nelem, elsize);
(gdb) 
#7  0x000000000097efaf in gfc_get_namespace (parent=parent@entry=0x2d069d0,
parent_types=parent_types@entry=0)
    at ../../repos/gcc-trunk-commit/gcc/fortran/symbol.cc:2869
2869      ns = XCNEW (gfc_namespace);

which implies the actual issue is likely much before!

[Bug fortran/108109] [ICE] gfortran compilation fails calling 'free()' with 'malloc(): mismatching next->prev_size (unsorted)'

[anlauf at gcc dot gnu.org]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Is this attached file to be preprocessed?  Or does it need special options?
Can't reproduce here.

[Bug fortran/108109] [ICE] gfortran compilation fails calling 'free()' with 'malloc(): mismatching next->prev_size (unsorted)'

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 54096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54096&action=edit
valgrind output.

(In reply to anlauf from comment #1)
> Is this attached file to be preprocessed?  Or does it need special options?
> Can't reproduce here.

I attached the valgrind output (for mainline) and the message fits to what
glibc diagnoses. There is simply an invalid READ – and the free is for a bogus
address (in the middle of an allocation).

As it is for a code which completely fails to compile, I don't think it is of
any priority at all - but I did not want to leave it unreported. (Main issue:
Several macros not defined, especially those which should expand to a string
literal.)

 * * *

Special option: In principle not, but for the main test file, I see differences
with and without '-cpp' and not a clear pattern. In particular:

No - it isn't. I just run: 'gcc-7 test.f90' (works), gcc-8 ... (works), gcc-9
(glibc's fatal message), gcc-10 (likewise), gcc-10/11/12 (works), mainline
(glibc's message).

Here, gcc-7 to gcc-10 are the Ubuntu version, gcc-11 to mainline are self
compiled. I checked and I don't have _MALLOC_PERTURB set.

The big program (MM_GPU_Library_Module.f90), I currently get the message with
'gfortran-9' with and without '-cpp' – but with gfortran mainline, I only get
it with -cpp. – I think I got it in different variants also before.

That's with Ubuntu 20.04.5 LTS + glibc 2.31-0ubuntu9.9.

(Often using something like MALLOC_PERTURB_=... helps, but here it doesn't;
probably because calloc and free are involved.)

[Bug fortran/108109] [ICE] gfortran compilation fails calling 'free()' with 'malloc(): mismatching next->prev_size (unsorted)'

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-12-14
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from anlauf at gcc dot gnu.org ---
On my system I don't see glibc complaining, independent of MALLOC_PERTURB_=,
however, with valgrind I do get an invalid read slightly deeper down, in

==21865== Invalid read of size 8
==21865==    at 0x95AD7D: add_dt_to_dt_list (resolve.cc:14470)
==21865==    by 0x95AD7D: add_dt_to_dt_list (resolve.cc:14464)
==21865==    by 0x95AD7D: resolve_fl_derived0(gfc_symbol*) [clone .part.0]
(resolve.cc:15152)

(Note the line numbers may slightly differ from yours.)

So confirmed.