Intel oneAPI segmentation fault on valid F2018 code

[Juergen_R_R]

The execution of the attached code gives a segmentation fault with oneAPI 2021.9, though I believe it is valid F2018 code. It works with the NAG compiler, but also segfaults with gfortran.

This is the backtrace

rogram received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff7c62859 in __GI_abort () at abort.c:79
#2 0x00007ffff7cd52da in __malloc_assert (
assertion=assertion@entry=0x7ffff7df98a8 "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", file=file@entry=0x7ffff7df53d6 "malloc.c", line=line@entry=2379, function=function@entry=0x7ffff7dfa030 <__PRETTY_FUNCTION__.13066> "sysmalloc") at malloc.c:298
#3 0x00007ffff7cd793f in sysmalloc (nb=nb@entry=96, av=av@entry=0x7ffff7e2cb80 <main_arena>) at malloc.c:2379
#4 0x00007ffff7cd8793 in _int_malloc (av=av@entry=0x7ffff7e2cb80 <main_arena>, bytes=bytes@entry=88) at malloc.c:4141
#5 0x00007ffff7cda154 in __GI___libc_malloc (bytes=88) at malloc.c:3058
#6 0x00000000004707a5 in _mm_malloc ()
#7 0x00000000004281a6 in for_allocate_handle ()
#8 0x000000000041309d in do_alloc_copy ()
#9 0x0000000000411cf5 in for_alloc_mold ()
#10 0x000000000040d23d in qn_containers_mp_qn_container_grow_ ()
#11 0x000000000040a6ad in qn_containers_mp_qn_array_append_ ()
#12 0x0000000000405044 in qn_containers_uti_mp_qn_containers_2_ ()
#13 0x0000000000404209 in MAIN__ ()

[andrew_4619]

Your sample code  is quite long and complicated and would take some time for me to to understand however I ran in in the debugger (in windows) to see how/where is crashes. It crashes in the %copy as the address being copied to is zero. But to me the assuage of move_alloc in the snippet below seems problematic as q_tmp is unallocated before the move_alloc. In my experience you allocate a new thing of different size, copy data to the new thing and the move the allocation from the old thing to the new thing deallocating the old thing in the process.

  subroutine qn_container_grow (qq)
    class(qn_container_t), intent(inout) :: qq

    class(qn_t), dimension(:), allocatable :: q_tmp

    call move_alloc (from = qq%q, to = q_tmp)
    allocate (qq%q (2 * size (q_tmp)), mold = q_tmp)
    call q_tmp%copy (qq%q(1:size(q_tmp)))

  end subroutine qn_container_grow

[Juergen_R_R]

Here is an even shorter reproducer of just 416 lines. The move_alloc is default procedure, and the to argument gets allocated by exection of move_alloc. The problem seems the execution of the copy procedure, it looks like that this incorrectly executed. Both qa and qq are of qn_array_t (extending qn_container_t). So it is (correctly) qn_array_copy that is invoked. This is then called with the argument

qq%q(1:size(q_tmp)). The argument is of type qn_array_t, otherwise the select type wouldn't match. It is the assignment in qn_array_copy that fails.

[andrew_4619]

Actually I have fallen foul of that well documented debugger bug, that says q_tmp is undefined when it isn't!

  subroutine qn_container_grow (qq)
    class(qn_container_t), intent(inout) :: qq

    class(qn_t), dimension(:), allocatable :: q_tmp

    call move_alloc (from = qq%q, to = q_tmp)
    if ( allocated( qq%q ) ) write (*, "(A)")  "* qq%q allocated"
    if ( allocated( q_tmp ) ) write (*, "(A)") "* qq_tmp allocated"
    allocate (qq%q (2 * size (q_tmp)), mold = q_tmp)
    call q_tmp%copy (qq%q(1:size(q_tmp)))

  end subroutine qn_container_grow

This code showed q_tmp is allocated  even if the debuggers indicates otherwise!

[Barbara_P_Intel]

Before I dive into this too deeply, @Juergen_R_R, have you resolved this?

I ran it on Linux with both ifort and ifx and got this traceback.

$ ifort -O0 -traceback repro.f90
$ a.out
[]

* Array of arrays

[[h(0) h(1)]]
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source      
libc.so.6          00007FE398DCDB70  Unknown               Unknown  Unknown
a.out              000000000046CAC4  Unknown               Unknown  Unknown
a.out              000000000040D695  Unknown               Unknown  Unknown
a.out              000000000040DCF5  Unknown               Unknown  Unknown
a.out              000000000040E8C7  Unknown               Unknown  Unknown
a.out              000000000040E96F  Unknown               Unknown  Unknown
a.out              0000000000407DF8  qn_containers_mp_         329  repro.f90
a.out              0000000000406EC5  qn_containers_mp_         288  repro.f90
a.out              0000000000408D3E  qn_containers_mp_         363  repro.f90
a.out              000000000040ACF2  qn_containers_uti         404  repro.f90
a.out              000000000040B10C  MAIN__                    415  repro.f90
a.out              00000000004041AD  Unknown               Unknown  Unknown
libc.so.6          00007FE398DB7B4A  Unknown               Unknown  Unknown
libc.so.6          00007FE398DB7C0B  __libc_start_main     Unknown  Unknown
a.out              00000000004040C5  Unknown               Unknown  Unknown
$

[Juergen_R_R]

Hi Barbara, thanks for the feedback. No, I didn't resolve this yet. This is not from the master of our software, but from an experimental branch, where we wrote a new data structure, polymorphic data types with allocatable arrays as components, with convenience functions for I/O, for "pop" and "push" in order to replace our existing data structure, based on a pointer implementation of "trie"s. The code at the moment only works with the NAG compiler. Both Intel and gfortran have problems, but from a different root cause I would say. In any case, this is beyond Fortran 2008, as it contains impure elemental recursive procedures, which I believe only started with Fortran 2018.

Cheers,   Juergen

[Barbara_P_Intel]

Okay. What output do you expect to see?

[Juergen_R_R]

---

@Barbara_P_Intel wrote:

Okay. What output do you expect to see?

---

Ah right, this is the expected output:

[]

* Array of arrays

[[h(0) h(1)]]
[[h(0) h(1)] [h(-1) h(0)]]

[Barbara_P_Intel]

Thanks for reducing the size of the reproducer!

I reproduced the seg fault with both ifx and ifort and filed a bug report, CMPLRLLVM-49773.

I will let you know when there's a fix.

[Barbara_P_Intel]

With ifx 2024.1 that was released last week, I get the output you expect! Please try this new compiler.