Segmentation fault with ixf/ifort

[Olsen__Oystein]

Hi,

I'm getting a segmentation fault with the latest ifx (2024.0) and ifort (2021.11.10). The attached example is a bit big, but it demonstrates the problem. The code works fine with gfortran and NAG Fortran. 

To extract, build and run

$ tar zxvf bug_derived_type_20231202_v4.tar.gz

$ cd bug_derived_type

$ make

$ ./test_derived_type

The segmentation fault happens on exit from the switch routine (line 511). Removing the antenna component on line 659 stops the segmentation fault from happening. Replacing the HSEarthTerminal and HSEarthTerminalVector with HSSurfaceAsset and HSSurfaceAssetVector in the main program also stops the segmentation fault from happening.

(The program reads a dataset from a text file, which is included, and attempts to sort the resulting vector object.)

Best regards,

Øystein

[Ron_Green]

I have tested this and I also see the segfault.  I used the 2024.0 compiler and our development branch - both show the bug.

This reproducer is perfect - a single file.  it's not too big, we can work with this.  I will isolate this down more and get a bug report on it.  Thank you for a very good reproducer!

[Ron_Green]

I forgot to follow up with the bug ID on this issue: CMPLRLLVM-54166

[Olsen__Oystein]

Any news on this issue? I just tested with 2025 and I still see the same crash. 

[Olsen__Oystein]

I believe I just found a work-around by changing the switch routine from:

  SUBROUTINE switch(this, k, l, mask)
    CLASS(HSVector), INTENT(INOUT) :: this
    INTEGER(I4B), INTENT(IN)       :: k, l
    LOGICAL(L1B), INTENT(IN)       :: mask

    CLASS(HSVariant), ALLOCATABLE  :: a, b

    IF (mask) THEN
       IF ( this%at(k)%isLessThan(this%at(l)) ) RETURN
    END IF


    ALLOCATE(a, SOURCE=this%at(k))
    ALLOCATE(b, SOURCE=this%at(l))

    CALL this%at(k)%assignHSVariant(b)
    CALL this%at(l)%assignHSVariant(a)

    DEALLOCATE(b)
    DEALLOCATE(a)
    RETURN
  END SUBROUTINE switch

to

  SUBROUTINE switch(this, k, l, mask)
    CLASS(HSVector), INTENT(INOUT) :: this
    INTEGER(I4B), INTENT(IN)       :: k, l
    LOGICAL(L1B), INTENT(IN)       :: mask

    CLASS(HSVariant), ALLOCATABLE  :: a(:), b(:)

    IF (mask) THEN
       IF ( this%at(k)%isLessThan(this%at(l)) ) RETURN
    END IF


    ALLOCATE(a, SOURCE=this%at(k:k))
    ALLOCATE(b, SOURCE=this%at(l:l))

    CALL this%at(k)%assignHSVariant(b(1))
    CALL this%at(l)%assignHSVariant(a(1))

    DEALLOCATE(b)
    DEALLOCATE(a)
    RETURN
  END SUBROUTINE switch

 This stops the segmentation fault that happened at DEALLOCATE(b)

[Devorah_H_Intel]

@Olsen__Oystein 
I tested with 2025 ifx, and there was no crash. It is fixed in 2025:

ifx -std18 -debug all -warn all -traceback -fp-stack-check -assume norealloc_lhs test_derived_type.f90 -o test_derived_type
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'
$ ./test_derived_type
READ
$ ifx -v
ifx version 2025.0.0
 

[Olsen__Oystein]

That is weird because it keeps crashing on my machines. On OpenSUSE tumbleweed:

acheron 10:12:16 bug_derived_type> loadifx 
 
:: initializing oneAPI environment ...
   -bash: BASH_VERSION = 5.2.37(1)-release
   args: Using "$@" for setvars.sh arguments: 
:: compiler -- latest
:: debugger -- latest
:: mpi -- latest
:: umf -- latest
:: oneAPI environment initialized ::
 
acheron 10:12:20 bug_derived_type> make
ifx test_derived_type.f90 -std18 -debug all -warn all -traceback -fp-stack-check -assume norealloc_lhs -o test_derived_type
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'
acheron 10:12:25 bug_derived_type> ./test_derived_type 
 
 ID:           0
       2572176.59428       2572107.87338       2566829.64041
       2566549.98101       2561086.59834       2560715.71641
       2549098.75982       2549038.75866       2548938.96895
       2529457.15562       2529436.43578       2517489.69299
       2506268.49268
 
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007F4545A41580  Unknown               Unknown  Unknown
test_derived_type  000000000040FA60  Unknown               Unknown  Unknown
test_derived_type  00000000004188F3  Unknown               Unknown  Unknown
test_derived_type  0000000000418B50  Unknown               Unknown  Unknown
test_derived_type  0000000000418C50  Unknown               Unknown  Unknown
test_derived_type  0000000000409764  switch                    511  test_derived_type.f90
test_derived_type  0000000000407848  sort                      449  test_derived_type.f90
test_derived_type  000000000040EFF9  test                      927  test_derived_type.f90
test_derived_type  000000000040519D  Unknown               Unknown  Unknown
libc.so.6          00007F4545A2A2AE  Unknown               Unknown  Unknown
libc.so.6          00007F4545A2A379  __libc_start_main     Unknown  Unknown
test_derived_type  00000000004050A5  Unknown               Unknown  Unknown
acheron 10:12:28 bug_derived_type> ifx -v
ifx version 2025.0.0

I get exactly the same crash on Ubuntu 22.04. That is with ifx version 2025.0.1.

[Olsen__Oystein]

I've done some additional tests, i.e. trying different options where the default settings is "varies" according to the manual. Adding --noauto as a compiler option stops the crash at my end.

However, that leads to other issues. For example, allocatable variables in functions and subroutines are then not deallocated by default.

FYI, this example works with ifort 2021.8.0 with no issues.

[Olsen__Oystein]

---

@Devorah_H_Intel wrote:

@Olsen__Oystein 
I tested with 2025 ifx, and there was no crash. It is fixed in 2025:

ifx -std18 -debug all -warn all -traceback -fp-stack-check -assume norealloc_lhs test_derived_type.f90 -o test_derived_type
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'
$ ./test_derived_type
READ
$ ifx -v
ifx version 2025.0.0
 

---

Based on this output, it looks like the included data file has been deleted (or corrupted) on your end. The test case stopped before the bug itself.  Can you please try to re-download the example attached to the first post in this thread?

FYI, The only correct output is:

 ID:           0
       2572176.59428       2572107.87338       2566829.64041
       2566549.98101       2561086.59834       2560715.71641
       2549098.75982       2549038.75866       2548938.96895
       2529457.15562       2529436.43578       2517489.69299
       2506268.49268

 ID:           0
       2572176.59428       2572107.87338       2566829.64041
       2566549.98101       2561086.59834       2560715.71641
       2549098.75982       2549038.75866       2548938.96895
       2529457.15562       2529436.43578       2517489.69299
       2506268.49268

Some versions of the intel compilers (ifort 2021.8.0 for example) do not crash, but the second block, which is written after the sort statement, is then corrupted  random values.