Bug 24829

Summary:	f951: internal compiler error: segmentation fault. Executable binary generated without -fsanitize=address flag, crashes with "malloc(): invalid next size (unsorted)"
Product:	Mageia	Reporter:	Adelson Oliveira <adelson.oliveira>
Component:	RPM Packages	Assignee:	Base system maintainers <basesystem>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	kernel, marja11
Version:	7
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	glibc (+gcc+kernel)	CVE:
Status comment:

Description Adelson Oliveira 2019-05-16 03:59:42 CEST

Upon compiling a fortran program with gfortran 8.3.1, I got the message "internal compiler error" and was told to submit a full bug report. This is why I'm reporting this. But I have to say that this cannot be a "full" bug report because I can't send a source test program to reproduce the reported bug up to now. Rather than giving a full bug report, I'm intending to call attention to some possible problem with glibc 2.29 and/or gcc 8.3.1 and/or kernel 5.1.
As a reference, googling around for a solution I've found this,

https://github.com/OpenTTD/OpenTTD/issues/7496.

First of all, before reaching the point at which the "internal compiler error" was issued, I was having problems with an executable binary generated by gfortran in mageia 7 beta (up to date) that crashed with the glibc message:

malloc(): invalid next size (unsorted)

The very same program, when compiled in another distro with glibc 2.12 and gfortran 8.3 does not crash, no error messages at all.

I've tried gfortran options as -g and -fsanitize=address with no helpful error message.
Curiously, as soon as I updated kernel 5.1.1 => 5.1.2, the compilation with -fsanitize=address generated an executable binary that doesn't crash, although a few messages on leaking memory are issued. Without the -fsanitize option, the binary still crashes with the same malloc error message.

Finally, in an attempt to correct for leaking memory messages with deallocation I've reached the "internal compiler error" message.

For what I've reported above, I think there is a good probability that glibc/gcc has some internal bug.

Hope this can be of help and if I finally get a source test program that I can upload here, this will be sent immediately.

Thanks

Comment 1 Adelson Oliveira 2019-05-16 16:14:14 CEST

Correcting for the bug report, the "internal compiler error" which motivated this report was my mistake. However, there is, in my opinion, something strange with the packages glibc, gcc, and/or kernel since executable binaries generated with/without -fsanitize=address flag does/does not run.

Now, I've corrected for all memory leaks and saw no message on array bounds trespassed but still, without the sanitize flag, the program crash with the message,

malloc(): invalid next size (unsorted)

Marja Van Waes 2019-05-18 13:35:37 CEST

CC: (none) => kernel, marja11
Assignee: bugsquad => basesystem
Summary: f951: internal compiler error: segmentation fault => f951: internal compiler error: segmentation fault. Executable binary generated without -fsanitize=address flag, crashes with "malloc(): invalid next size (unsorted)"

Comment 2 Adelson Oliveira 2019-05-21 02:41:37 CEST

I've found the culprit for both problems. Both points to misleading error messages on real programming code problems. I mean,

I did the following mistakes:

1- Tried to handle a component of an allocatable fortran type (structure) without proper reference to the structure index itself; Other fortran compilers do issue clear error messages to the programmer but gfortran got a "internal compiler error";

2- Tried to copy an array a1 to an array a2 with instruction a1=a2 with different sizes of a1 and a2. Other fortran compilers produce executable binaries that do  issue clear runtime error messages to the programmer on "unconformable arrays" but gfortran (glibc 2.29) generated a code that crashes with "malloc(): invalid next size(unsorted)" messages.


In summary, this has nothing to do with mageia itself. These are bugs to be reported to gcc.gnu.org. As soon as I have a small set of fortran lines that reproduce this error, I'll report to GNU.

I would like to close this bug.

Thanks and I'm sorry to report this bug here.

Comment 3 David Walser 2019-08-10 23:55:21 CEST

You could have closed it, but doing so now.

Resolution: (none) => INVALID
Status: NEW => RESOLVED