GNU very simple interoperable c Fortran module integer demo segfault

Help
1

I just want one that works. I even updated bookworm, then installed Trixie and still got the same error (except the number before the word Segmentation changes). All this code (case changes are mine) comes from tries with Chrome’s AI question answer (on 2 different days). It looks very simple.

I did find “Security update for GLIBC for a risk 1st noted in 2018 and an accepted alteration last year + a comment that the fix broke (old code). No comment about what code uses it. I have written lots of interoperable demo programs for functions and subroutines, but NEVER had a segmentation fault with them. I really don’t want to abandon the idea of a global module’s interoperable storage type is not currently doable.

How might I go about understanding where this segmentation comes from? [I don’t have any C program debugging experience beyond printf statements.]

$ cat fortran_module.f90
MODULE fortran_module
USE, INTRINSIC :: ISO_C_BINDING
IMPLICIT NONE
INTEGER(C_INT), BIND(C, name=“c_access_int”) :: fortran_int
CONTAINS
SUBROUTINE set_fortran_int(value) BIND(C, name=“set_fortran_int”)
INTEGER(C_INT), INTENT(IN) :: value
fortran_int = value
END SUBROUTINE set_fortran_int
END MODULE fortran_module

$ cat c_program.c
#include <stdio.h>
extern int c_access_int;
extern void set_fortran _int(int_value);

int main(void) {
printf(“Initial value of the Fortran integer: %d\n”, c_access_int);
c_access_int = 42;
printf(“Value after direct C modification: %d\n”, c_access_int);
set_fortran_int(99);
printf(“value after modification by Fortran subroutine: %d\n”, c_access_int);
return 0;
}

$ cat compile_link_and_run.bash
#! /bin/bash
gfortran -c fortran_module.f90
gcc -c c_program.c
gfortran c_program.o fortran_module.o -o mixed_program
./mixed_program
-------- output ------ of that
Initial value of the Fortran integer: 0
Value after direct C modification: 42
./compile_link_and_run.bash: line 5: 5087 Segmentation fault ./mixed_program

$nm -u mixed_program
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w __cx_finalize@GLIBC_2.2.5
w __gmon_start
U __libc_start_main@GLIBC_2.34
U __ printf@GLIBC_2.2.5

2

This should do the trick.

3

Btw, use of an unitialized variable is not a portable practice and can be dangerous: CWE - CWE-457: Use of Uninitialized Variable (4.19.1)

You can set an initial value for portability:

INTEGER(C_INT), BIND(C, name=“c_access_int”) :: fortran_int = 0
4

Yes those suggestions made it work.

The $ nm stuff must be a “red herring” for me, so the report stayed the same.

I have not tried to “correct” a Chrome AI wrong answer. Do you think that if I ask my question by adding without “, VALUE” would be helpful or maybe saying, “Do I have to use ‘pass by value’?”

I don’t understand how much Interoperabilty coding is done for us. I would have thought that as much as we are told that c expects value so one or the other of Fortran or C must accommodate that expectation. That seemed to be relaxed in later versions of interoperability .. at least when doing functions and subroutines .. because all that is needed is an asterisk in front of the variable(s) in the c code. The AI missed that when showing the 2 Fortran examples (or possibly I am blind to its poor choice of naming the Fortran variable …..value….. !

Thank you for such swift help. I can go home and rest without JOTS (jobbing on the sleep).

George Wyche