public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/112828] New: Abort with malloc(): corrupted top size
@ 2023-12-02 23:12 townsend at astro dot wisc.edu
2023-12-03 13:38 ` [Bug fortran/112828] " fxcoudert at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: townsend at astro dot wisc.edu @ 2023-12-02 23:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
Bug ID: 112828
Summary: Abort with malloc(): corrupted top size
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
Created attachment 56768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56768&action=edit
MWE demonstrating problem
When I compile the attached MWE with
gfortran -o test test.f90
...I get the following runtime error:
malloc(): corrupted top size
Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
#0 0x7f13a2e7760f in ???
#1 0x7f13a2ec500c in ???
#2 0x7f13a2e77571 in raise
#3 0x7f13a2e614b1 in abort
#4 0x7f13a2e623b4 in ???
#5 0x7f13a2ece874 in ???
#6 0x7f13a2ed1fdf in ???
#7 0x7f13a2ed2b59 in __libc_malloc
#8 0x40191a in MAIN__
#9 0x401c8c in main
Aborted
If I comment out the first allocate statement (the one with the STAT argument),
then the program runs without problem (even though this statement isn't
actually executed). There are a number of other things that make the bug go
away; e.g., shrinking the length of the character variables in the main program
to 20 or smaller. Setting the length to 21 still runs without error, but the
second element of c_r ends up with some junk in it, viz:
foo foo A
cheers,
Rich
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/112828] Abort with malloc(): corrupted top size
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
@ 2023-12-03 13:38 ` fxcoudert at gcc dot gnu.org
2023-12-03 15:01 ` townsend at astro dot wisc.edu
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2023-12-03 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I cannot reproduce this on macOS with gfortran 13.2.0
Could you give more details on what compiler version, what target, etc?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/112828] Abort with malloc(): corrupted top size
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
2023-12-03 13:38 ` [Bug fortran/112828] " fxcoudert at gcc dot gnu.org
@ 2023-12-03 15:01 ` townsend at astro dot wisc.edu
2023-12-03 16:28 ` townsend at astro dot wisc.edu
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: townsend at astro dot wisc.edu @ 2023-12-03 15:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #2 from Rich Townsend <townsend at astro dot wisc.edu> ---
The problem manifests with gfortran 13.1.0 on Linux/x86_64. I've run into
similar looking problems on MacOS/Arm, but the MWE I provided seems to work OK
on Arm.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/112828] Abort with malloc(): corrupted top size
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
2023-12-03 13:38 ` [Bug fortran/112828] " fxcoudert at gcc dot gnu.org
2023-12-03 15:01 ` townsend at astro dot wisc.edu
@ 2023-12-03 16:28 ` townsend at astro dot wisc.edu
2023-12-03 16:54 ` townsend at astro dot wisc.edu
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: townsend at astro dot wisc.edu @ 2023-12-03 16:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #3 from Rich Townsend <townsend at astro dot wisc.edu> ---
I can get the MWE to barf on MacOS/Arm (Sonoma 14.1.1), gfortran 13.1.0, by
changing the length of the character vars in the main program from 64 to 16.
The error is now:
In file 'test.f90', around line 49: Error allocating 211106259502048 bytes:
Cannot allocate memory
Error termination. Backtrace:
#0 0x102d77617
#1 0x102d781b7
#2 0x102d78457
#3 0x10275f5bb
#4 0x10275fc37
#5 0x10275f84f
#6 0x10275fc87
Once again, commenting out the allocate w/ STAT line makes the problem go away.
It seems as though having two allocate invocations (one with stat, one without)
is causing some kind of memory corruption.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/112828] Abort with malloc(): corrupted top size
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
` (2 preceding siblings ...)
2023-12-03 16:28 ` townsend at astro dot wisc.edu
@ 2023-12-03 16:54 ` townsend at astro dot wisc.edu
2023-12-03 18:33 ` townsend at astro dot wisc.edu
2023-12-03 20:45 ` anlauf at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: townsend at astro dot wisc.edu @ 2023-12-03 16:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #4 from Rich Townsend <townsend at astro dot wisc.edu> ---
Another data point for MacOS/Intel (10.13.6, High Sierra) -- with the character
vars set to length 64, the crash is as follows:
test(3287,0x7fff8fc11380) malloc: *** error for object 0x7fe44cc03b58:
incorrect checksum for freed object - object was probably modified after being
freed.
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
#0 0x105c19a5e
#1 0x105c18c1d
#2 0x7fff57818f59
Abort trap: 6
Again, commenting out the allocate(..., STAT=stat) line makes the problem go
away. Reducing the length to <=24 also resolves the problem.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/112828] Abort with malloc(): corrupted top size
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
` (3 preceding siblings ...)
2023-12-03 16:54 ` townsend at astro dot wisc.edu
@ 2023-12-03 18:33 ` townsend at astro dot wisc.edu
2023-12-03 20:45 ` anlauf at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: townsend at astro dot wisc.edu @ 2023-12-03 18:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #5 from Rich Townsend <townsend at astro dot wisc.edu> ---
One more data point: I tried with gfortran 13.2.0 on Linux/Intel and get the
same result as for 13.1.0.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/112828] Abort with malloc(): corrupted top size
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
` (4 preceding siblings ...)
2023-12-03 18:33 ` townsend at astro dot wisc.edu
@ 2023-12-03 20:45 ` anlauf at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-12-03 20:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2023-12-03
Status|UNCONFIRMED |NEW
Keywords| |wrong-code
CC| |anlauf at gcc dot gnu.org
--- Comment #6 from anlauf at gcc dot gnu.org ---
I get this crash with all gfortran versions (>= 7) on x86_64-pc-linux-gnu.
Sometimes optimization needs to be enabled to see this.
Replacing in reallocate the line
character(LEN(array)), allocatable :: array_new(:)
with the actual (constant) length fixes the issue, e.g.
character(LEN=64), allocatable :: array_new(:)
This may be a hint.
In my tests the stat variable only needs to be accessed by the line
if (PRESENT(stat))
it needs not be set explicitly.
Compiling with -fsanitize=address gives at runtime:
- when compiled with -O0:
==30489==ERROR: AddressSanitizer: requested allocation size 0x515f9880000
(0x515f9881000 after adjustments for alignment, red zones etc.) exceeds maximum
supported size of 0x10000000000 (thread T0)
#0 0x1457e8eb4527 in malloc
../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
...
- with -Og and higher:
==30533==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x502000000071 at pc 0x152c5cbc8a79 bp 0x7fff0a124100 sp 0x7fff0a1238c0
WRITE of size 64 at 0x502000000071 thread T0
...
(details depend on optimization level).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-12-03 20:45 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-02 23:12 [Bug fortran/112828] New: Abort with malloc(): corrupted top size townsend at astro dot wisc.edu
2023-12-03 13:38 ` [Bug fortran/112828] " fxcoudert at gcc dot gnu.org
2023-12-03 15:01 ` townsend at astro dot wisc.edu
2023-12-03 16:28 ` townsend at astro dot wisc.edu
2023-12-03 16:54 ` townsend at astro dot wisc.edu
2023-12-03 18:33 ` townsend at astro dot wisc.edu
2023-12-03 20:45 ` anlauf at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).