LLVM (ifx): a higher-order function causes segmentation fault on EndeavourOS

[EKawashima]

Consider the following Fortran file:

program main
  implicit none
  integer :: n
  n = 0
  call f(1)             ! OK
  print *, n
  call higher_order(f)  ! segmentation fault occurs if ifx compiles with -O0
  print *, n
contains
  subroutine f(arg)
    implicit none
    integer, intent(in) :: arg
    n = n + arg
  end subroutine

  subroutine higher_order(func)
    implicit none
    interface
      subroutine func(arg)
        integer, intent(in) :: arg
      end subroutine
    end interface
    call func(1)
  end subroutine
end program

On EndeavourOS (GCC and libc are 13.1.1 and 2.37, respectively), if the file is compiled by ifx (Version 2023.1.0 Build 20230320) with -O0, segmentation fault occurs:

           1
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          000014FAE4C4FAB0  Unknown               Unknown  Unknown
Unknown            00007FFDC84985D8  Unknown               Unknown  Unknown

The program works successfully if

• compiled by ifx with -O1 or higher
• compiled by ifort (Version 2021.9.0 Build 20230302_000000) with -O0 or higher

No warnings are issued with -std18 -warn all.

On Rocky Linux 8.7, where GCC and libc are respectively 8.5.0 and 2.28, segmentation fault does not occur even if compiled with -O0.

[jimdempseyatthecove]

A segmentation fault is definitely an error in the compiler generated code.

Note, contained procedures have implicit interfaces be it from within the parent procedure or other contained procedures.

Do you get the error without your (unnecessary) interface?

Jim Dempsey

[Steve_Lionel]

As another data point, the program runs fine with ifx -Od (equivalent to -O0) on Windows. That the segfault occurs in libc is peculiar.

[Ron_Green]

I'm trying to find a system with glibc 2.37.  Newest I have is glibc 2.36 which runs just fine.  Ubu 22.10.  I can try to upgrade to Ubu 23.04 perhaps.

But I have to tell you the company position:  You are using an unsupported OS and version.  Your glibc has not been validated. 

could you compile adding both

-g -traceback

and re-run so we get a traceback to the source line that is seg faulting?

[EKawashima]

Thank you for your quick replies.

---

could you compile adding both

-g -traceback

---

The following is the output:

           1
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007F823FB2FAB0  Unknown               Unknown  Unknown
Unknown            00007FFC961C4EB8  Unknown               Unknown  Unknown

gdb backtrace:

(gdb) bt
#0  0x00007fffffff85a8 in ?? ()
#1  0x0000000000405312 in main::higher_order (func=0x4052c0bb49) at a.f90:23
#2  0x0000000000405253 in main () at a.f90:7
#3  0x000000000040517d in main ()

[Ron_Green]

System Requirements shows the versions and distros we officially support.  I do not have a server I can update to that version of glibc and gcc.  And I'm afraid it would only tell us what we already know: the compiler just does not support this bleeding edge distro/version. I will try to find a server, and also see when gcc 13 and your glibc are expected to be supported.

[EKawashima]

Thank you for your replies and kind attention.

It is inlining that the program runs successfully if compiled by ifx and -O1:

FC	compile options	result
ifx	-O0	segmentation fault
ifx	-O1 -fno-inline	segmentation fault
ifx	-O1	OK
ifort	-O0	OK

[EKawashima]

ifort and gfortran issue the following warning in linkage on EndeavourOS:

ld: warning: a.o: requires executable stack (because the .note.GNU-stack section is executable)

Hence I tried the following linkers

• bfd (the default): 2.40.0
• gold: 1.16
• lld: 15.0.7

and options (https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments

FC	linker	compile option	link option	result
ifx	bfd	-O0		segmentation fault
ifx	gold	-O0		success
ifx	lld	-O0		segmentation fault
ifx	bfd	-O0	-Wl,-z,execstack	success
ifx	gold	-O0	-Wl,-z,execstack	success
ifx	lld	-O0	-Wl,-z,execstack	success
ifx	bfd	-O0	-Wl,-z,noexecstack	segmentation fault
ifx	gold	-O0	-Wl,-z,noexecstack	segmentation fault
ifx	lld	-O0	-Wl,-z,noexecstack	segmentation fault
ifx	bfd	-O1		success
ifx	gold	-O1		success
ifx	lld	-O1		success
ifx	bfd	-O1	-Wl,-z,execstack	success
ifx	gold	-O1	-Wl,-z,execstack	success
ifx	lld	-O1	-Wl,-z,execstack	success
ifx	bfd	-O1	-Wl,-z,noexecstack	success
ifx	gold	-O1	-Wl,-z,noexecstack	success
ifx	lld	-O1	-Wl,-z,noexecstack	success
ifort	bfd	-O0		success
ifort	gold	-O0		success
ifort	lld	-O0		segmentation fault
ifort	bfd	-O0	-Wl,-z,execstack	success
ifort	gold	-O0	-Wl,-z,execstack	success
ifort	lld	-O0	-Wl,-z,execstack	success
ifort	bfd	-O0	-Wl,-z,noexecstack	segmentation fault
ifort	gold	-O0	-Wl,-z,noexecstack	segmentation fault
ifort	lld	-O0	-Wl,-z,noexecstack	segmentation fault

On Rocky Linux 8.7, where ld.bfd and ld.gold are respectively 2.30-117.el8 and 1.15, the behaviours are independent on the linker:

FC	compile option	link option	result
ifx	-O0		success
ifx	-O0	-Wl,-z,execstack	success
ifx	-O0	-Wl,-z,noexecstack	segmentation fault
ifx	-O1		success
ifx	-O1	-Wl,-z,execstack	success
ifx	-O1	-Wl,-z,noexecstack	success
ifort	-O0		success
ifort	-O0	-Wl,-z,execstack	success
ifort	-O0	-Wl,-z,noexecstack	segmentation fault

On both OS's, gfortran 13.1.1/8.5.0 behaves the same as ifort.

So perhaps there is something wrong with linkage

Many thanks.

[jimdempseyatthecove]

>>ld: warning: a.o: requires executable stack (because the .note.GNU-stack section is executable)

...

>>#0 0x00007fffffff85a8 in ?? ()

>>#1 0x0000000000405312 in main::higher_order (func=0x4052c0bb49) at a.f90:23

The above outputs (0x00007fffffff85a8 in ?? ()) looks as if the code being executed has been created at runtime and is placed on the stack .AND. the particular linker/option/lack-of-option is annotating that the stack segment is to be set to read/write but inhibit execute.

It may be of interest to produce two load maps using a linker that produces both the success and segmentation fault. This might provide additional input.

I suspect that there is something in the selected CRTL that is generating code at runtime, that is placed on the stack or on the heap.

Note, historically, some viruses would do this, and to defeat this, the CPU selector registers added flags for Read, Write, and Execute.

Note-2, the above is not to be a statement to say your program (or CRTL) has a virus. Rather, something unusual is happening that requires the stack be flagged for permission to execute.

Jim Dempsey