From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5028538493C7; Wed, 14 Dec 2022 20:51:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5028538493C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671051083; bh=DKnCDUH3K9whcbfcPk3Jpdz7ubR6ROQlea7e7iEyboM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=V+FzomHPwxKE56EUvJ8NfazRr4bWcxgBSDJYnHev+sOfTY5tzWzAJ8BmmJCXdl8Rr JC7jFw2F24+7mA3HKv5jp4VBt3lvTH7Xd/P7YJ5ZxhCBQ0dT076MZ52O8wAF0a/7TD LNn498QfO6FtE8dnVJviHSD+E21lpFbhbNnbQuc4= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/108109] [ICE] gfortran compilation fails calling 'free()' with 'malloc(): mismatching next->prev_size (unsorted)' Date: Wed, 14 Dec 2022 20:51:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108109 --- Comment #2 from Tobias Burnus --- Created attachment 54096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54096&action=3Dedit valgrind output. (In reply to anlauf from comment #1) > Is this attached file to be preprocessed? Or does it need special option= s? > 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 =E2=80=93 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 issu= e: 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 differe= nces 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 wi= th 'gfortran-9' with and without '-cpp' =E2=80=93 but with gfortran mainline, = I only get it with -cpp. =E2=80=93 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_=3D... helps, but here it doesn'= t; probably because calloc and free are involved.)=