Fortran与R接口调用时Allocatable数组重复分配错误排查

The Problem #

I'm integrating modern Fortran code with R, and keep hitting this error when trying to call my shared object (HX.so) multiple times in the same R session:

forrtl: severe (151): allocatable array is already allocated

I can run the routine once successfully, but to run it again, I have to unload and reload the shared object every time. Restarting R works too, but this is inefficient for my sensitivity analysis work that requires repeated calls.

Context & Debugging Details #

• Compilation: I used ifort with these flags to build HX.so:

  F90 = ifort
  FFLAGS = -O3 -fpic -r8 -g -check -traceback
  LDFLAGS = -lnetcdff -lnetcdf -shared
  

• R Call Pattern: My R code uses .Fortran() to invoke the routine, like this:

  dyn.load("HX.so")
  years <- c(2007, 2008, 2009)
  n_years <- as.integer(length(years))
  
  run_model <- function(pa = params) {
    out <- .Fortran('HX', pa, n_years, array(as.numeric(0), dim = c(14,6,n_years)))
    return(out)
  }
  
  # Works first time, fails second without dyn.unload/dyn.load
  out1 <- run_model(c(30,2))
  out2 <- run_model(c(30,2))  # Throws error here
  

• Debugging Steps:
  • Checked for missing deallocations, fixed some, but the error persisted.
  • Confirmed the Fortran routine runs to completion with a WRITE (*,*) 'END' statement at the end.
  • Compiling with -check flagged the error to line 27 of my init_ subroutine (called from the main hx_ routine), where an allocatable array was never deallocated.

The Fix #

The root cause was unfreed allocatable arrays I'd overlooked during initial checks. When running the Fortran code as a standalone executable, the OS cleans up memory when the program exits—but when it's a shared object loaded into R's persistent process, those arrays stay allocated between calls.

Adding explicit DEALLOCATE() statements for all allocatable arrays (including the one in init_) at the end of their respective routines resolved the error. Now I can call the Fortran routine as many times as needed in the same R session without reloading the shared object.

Answering Your Compiler Behavior Question #

Great question! Here's why this didn't show up in the standalone executable but did in the shared object:

• Standalone Executables: When your Fortran program finishes, the operating system reclaims all memory used by the process—including any allocatable arrays you forgot to deallocate. The leak is hidden because the process dies immediately after running.
• Shared Objects in R: The shared object runs within R's long-lived process. Memory isn't automatically cleaned up between routine calls because the process stays alive. The allocatable array remains allocated from the first call, so when the second call tries to allocate it again, you hit the "already allocated" error.

Compilers like ifort don't always flag missing deallocations by default (especially outside loops) because in standalone programs, it's often harmless. But when working with shared objects or long-running processes, proper deallocation becomes critical to avoid state leakage between calls—this is why it's such an important practice for reusable library code!

内容的提问来源于stack exchange，提问作者Annemarie Eckes