[flang] Runtime segfault with valid code

[nncarlson]

Here is a small reproducer for a flang bug tripped by our production code. In the example, a call-back subroutine is passed to another subroutine which invokes the call-back. The salient feature which results in the segfault is that the call-back is an internal procedure that accesses a variable from its parent by host association.

module factory

  abstract interface
    subroutine callback
    end subroutine
  end interface

contains

  subroutine alloc_flux_bc
    integer :: n
    n = 42
    call iterate_list(my_cb)
  contains
    subroutine my_cb
      print *, n ! N ACCESSED FROM PARENT BY HOST ASSOCIATION
    end subroutine
  end subroutine
  
  subroutine iterate_list(cb)
    procedure(callback) :: cb
    call cb ! SEGFAULTS HERE
  end subroutine

end module

program main
use factory
call alloc_flux_bc
end program

With the main branch code (as of today), running the compiled code segfaults; the expected output is simply "42". NAG, gfortran, and Intel oneAPI all compile and run this example without error.

[klausler]

It works for me here using the latest flang-new from llvm-project/main sources on x86-64 Linux. Can you share any more details?

[nncarlson]

I'm on x86-64 Fedora 41 and just built (in-tree) from a clone of the llvm-project repo. However, I was just using flang, and see now there is also a flang-new binary. I still get a segfault with flang-new. What is the difference between the two? I'm really a neophyte with flang.

Actually for me both flang and flang-new have the same md5sum.

Here's my cmake configure script, fwiw:

installdir=/opt/llvm/22.0.0-51163c5
rm -rf build
mkdir build
(cd build; \
  cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$installdir \
    -DLLVM_ENABLE_PROJECTS="clang;flang;mlir;lldb" \
    -DLLVM_ENABLE_RUNTIMES="compiler-rt;flang-rt;openmp" \
    -DLLVM_TARGETS_TO_BUILD=host \
    -G Ninja ../llvm; \
  ninja; \
  ninja install)

[klausler]

What does flang -v tell you?

[nncarlson]

flang version 22.0.0git (git@github.com:llvm/llvm-project 51163c5dbdea72139ee4b93f5de7e652d30dea9f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/22.0.0-51163c5/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/14
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/14
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

That's the system gcc. I have other locally-built gcc (15.x) that I could load and recompile flang if that mattered. What exactly is clang/flang using from gcc?

[klausler]

That all seems reasonable, unfortunately. Are you using some kind of secure environment that disables execution permission on the stack, at least by default? LLVM's trampolines unfortunately still work that way.

[klausler]

Try objdump -x a.out | more and look at the program header for STACK. It will look something like

   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx

See whether the flags are indeed rwx or just rw.

[nncarlson]

" secure environment that disables execution permission"

Argh. I did just upgrade from F39 to F41, and have encountered such issues. (I initially tried F42 with glibc 2.41 on another system and that totally broke a number of different programs with the executable stack issue, so I backed off my upgrade to F41 with glibc 2.40.) Initially most of the code tests with oneAPI was failing but disabling selinux resolved that. But I'm unaware of any other "secure" environment that I might have enabled. This was a completely vanilla Fedora installation.

[sscalpone]

See if this helps on the link-line "-Wl,-zexecstack"

[nncarlson]

I'll try that, but I just did execstack -s ./a.out and that resolved the problem.

[klausler]

This isn't something that you shouldn't have to do, of course. I think there might be an open PR for this, we're looking right now for it.

[nncarlson]

The command line option did the trick too. I sense this is going to be a real nuisance for all compilers, especially when distros move to glibc 2.41 which is unforgiving about executable stacks. Thanks for you help and sorry about the false problem.

[sscalpone]

Help is on the way! #151754