Fortran-C interop segfault when using CFI_allocate

This could be related to the previous bug in the Fortran-C interop features I reported, but since the conditions around the bug and symptoms are different I believe this is two different problems. Therefore I make a new thread about this one.

I have a main Fortran program program.F90:

PROGRAM main
    USE, INTRINSIC :: ISO_C_BINDING, ONLY: c_float
    IMPLICIT NONE

    INTERFACE
        SUBROUTINE check_array(res) BIND(C)
            IMPORT :: c_float
            REAL(c_float), INTENT(inout), ALLOCATABLE :: res(:, :, :)
        END SUBROUTINE check_array
    END INTERFACE

    REAL, ALLOCATABLE :: my_array(:, :, :)

    CALL check_array(my_array)
    WRITE(*, *) "First element of my_array: ", my_array(1, 1, 1)
    WRITE(*, *) "Lower bound of my_array: ", LBOUND(my_array)
    WRITE(*, *) "Size of my_array: ", SHAPE(my_array)
    WRITE(*, *) "Last element of my_array: ", my_array(SIZE(my_array, 1), &
        SIZE(my_array, 2), SIZE(my_array, 3))
END PROGRAM main

and an accompanying C++ routine in check_array.cpp:

#include <ISO_Fortran_binding.h>

#include <iostream>
#include <cassert>

extern "C" {
    void check_array(CFI_cdesc_t* data) {
        assert (data->rank == 3);
        assert (data->type == CFI_type_float);

        // If already allocated - free
        if (data->base_addr) CFI_deallocate(data);

        // Allocate the Fortran array
        const CFI_index_t lower_bounds[3] = {1, 1, 1};
        const CFI_index_t upper_bounds[3] = {3, 3, 1996};
        int ierr = CFI_allocate(data, lower_bounds, upper_bounds, 0);
        assert (ierr == CFI_SUCCESS);

        const size_t nelems =
            (data->dim[0].extent - data->dim[0].lower_bound + 1) *
            (data->dim[1].extent - data->dim[1].lower_bound + 1) *
            (data->dim[2].extent - data->dim[2].lower_bound + 1);
        std::cout << "nelems: " << nelems << std::endl;

        // Fill array with some data
        float* ptr = reinterpret_cast<float*>(data->base_addr);
        for (size_t i = 0; i < nelems; ++i) {
            ptr[i] = static_cast<float>(i);
        }
    }
}

Again, this works with Intel, GNU and NAG compilers. The output should be something like:

$ ./test_cfi 
nelems: 17964
 First element of my_array:    0.00000000    
 Lower bound of my_array:            1           1           1
 Size of my_array:            3           3        1996
 Last element of my_array:    17963.0000

When compiling with nvfortran and nvc++ I get a segfault:

$ ./test_cfi 
nelems: 17964
Segmentation fault (core dumped)

The segfault occur when writing into the allocated array (ptr[i] = static_cast<float>(i);). I strongly suspect that CFI_allocate is not allocating the correct memory…

I am using the following nvfortran version:

$ nvfortran --version

nvfortran 24.3-0 64-bit target on x86-64 Linux -tp alderlake 
NVIDIA Compilers and Tools
Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.

Again, thanks for your effort.

Hey again!

I agree that I believe this is a bug in our compiler’s behavior. It’s unclear if the pointer is being set up incorrectly by the compiler or if its the initial CFI_allocate set up not creating the right memory - but I have raised a bug report #35728 with our compiler engineering team and hope to have it evaluated and triaged soon, with a goal of having a fix potentially by 24.7. I linked it with bug report #35723, which you reported yesterday, and hopefully we’ll get them both resolved at the same time!

Thank you for bringing this to our attention! If you run into any other issues, feel free to let us know.

Cheers,

Seth.

Thanks for looking into this. This is important for interfacing other libraries that can do things like reading JSON files (nlohmann json) and parsing expressions (exprtk) in a Fortran application.

Hi hakostra,

I just heard back from engineering - we should have a fix for this issue in our next release, NVHPC 24.7 as the engineer just pushed a fix for it into our internal development compiler. I haven’t heard back about your other issue yet - but at least this issue should be resolved!

Cheers,

Seth.

@hakostra - I can confirm that this has been fixed in NVHPC 24.7! Hope this helps. Thanks for letting us know about the issue and please let us know about any other issues you run into!

I have now installed version 24.7 and this works like it should. Thanks!