Seg fault calling procedure pointer component associated with an internal procedure.

[everythingfunctional]

This one is another doozy. It again comes originally from trying to run the test suite for my unit testing framework veggies (https://gitlab.com/everythingfunctional/veggies). Clone that repo and running the test suite (i.e. `fpm test --compiler ifx`) segfaults. Some minor sleuthing with the debugger and I was able to identify calling a procedure pointer component associated with an internal procedure that references a local variable as the most likely culprit. The attached reproducer does just this. The strange thing is the reproducer does not segfault if you don't use any compiler options. It does segfault if you use `-g`. I haven't found any set of compiler flags that will let the veggies test suite run successfully.

[Xiaoping_D_Intel]

Which version of ifx compiler are you using? I couldn't reproduce the seg-fault error using ifx compiler from oneAPI 2025.0.

[everythingfunctional]

I'm using

ifx (IFX) 2025.0.0 20241008
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

Did you include the `-g` flag? As I mentioned, the example doesn't segfault without it, but my real project does.

[Xiaoping_D_Intel]

Yes. Here is what I got:

$ ifx -V

Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.0 Build 20241008

Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

$ ifx -g example.f90

ifx: remark #10440: Note that use of a debug option without any optimization-level option will turnoff most compiler optimizations similar to use of '-O0'

$ ./a.out

$

[everythingfunctional]

Strange. Here's what I get:

$ ifx -g example.f90 -o example
ifx: remark #10440: Note that use of a debug option without any optimization-level option will turnoff most compiler optimizations similar to use of '-O0'
$ ./example 
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007EFC8EC4C1D0  Unknown               Unknown  Unknown
Unknown            00007FFC9A6309D0  Unknown               Unknown  Unknown
$ gdb-oneapi ./example
GNU gdb (Intel(R) Distribution for GDB* 2025.0.0) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.; (C) 2024 Intel Corp.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.

For information about how to find Technical Support, Product Updates,
User Forums, FAQs, tips and tricks, and other support information, please visit:
<http://www.intel.com/software/products/support/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./example...
(gdb) run
Starting program: /home/brad/scratch/intel-proc-pointer-comp-bug/example 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007fffffffd240 in ?? ()
(gdb) bt
#0  0x00007fffffffd240 in ?? ()
#1  0x00000000004051c5 in test_case_m::run_it (self=...) at example.f90:29
#2  0x000000000040531b in test_item_m::run_it (self=...) at example.f90:58
#3  0x00000000004054d6 in demo_m::demo () at example.f90:74
#4  0x000000000040551c in example () at example.f90:84

[Xiaoping_D_Intel]

Can you attach your executable file "example"?

[everythingfunctional]

Here you go (had to zip it due to allowed file types).

[Xiaoping_D_Intel]

The seg-fault is caused by the missing of executable stack flag in your executable file. The program will jump to address "0x00007fffffffd240" on the stack and then jump back to subroutine "internal". If the stack has no executable attribute bit set it will crash for protection. To check the executable attribute bit of the stack:

My executable:

$ readelf -l a.out |grep GNU_STACK -A 1

 GNU_STACK   0x0000000000000000 0x0000000000000000 0x0000000000000000

         0x0000000000000000 0x0000000000000000 RWE  0x10 // Executable is set

$ readelf -l example |grep GNU_STACK -A 1

 GNU_STACK   0x0000000000000000 0x0000000000000000 0x0000000000000000

         0x0000000000000000 0x0000000000000000 RW   0x10 // Executable not set

You can aslo double confirm the cause of the error by forcing executable stack bit by:

• Appending "-Xlinker -z -Xlinker execstack" option to your compilation command line to explicitly set it

or

• Change the setting of the executable by command "execstack -s example" // You may need ask your system admin to install "execstack" utility

and then run it again.

It seems the ld linker on our systems have different default behavior. Can you provide some info about your system configuration including:

• OS type and version
• binutil version from the output of command "ld -v"
• GCC version

[everythingfunctional]

I see. That would make sense. I reported an issue about the exact same thing to flang recently. https://github.com/llvm/llvm-project/issues/104798

My OS is: Arch Linux,

$ uname -a
Linux shiney 6.12.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 06 Dec 2024 11:15:43 +0000 x86_64 GNU/Linux`

$ ld -v
GNU ld (GNU Binutils) 2.43.0

$ gcc --version

gcc (GCC) 14.2.1 20240910
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Xiaoping_D_Intel]

Thanks for the info. We have already had a bug report addressing it and will fix it in future product.