Skip to content

Segmentation fault in PMPI_File_close() during output writing (OpenMPI 4.1.7, SU2 v8.5.0) #2852

Description

@zeeshan1043

Segmentation fault in PMPI_File_close() during output writing (OpenMPI 4.1.7, SU2 v8.5.0)

Environment

  • SU2 Version: v8.5.0 ("Harrier")
  • Commit: bc15466602a687d6fb796d5df7a12ce3fde0949a
  • Operating System: Rocky Linux (HPC cluster)
  • Compiler: GCC
  • MPI: OpenMPI 4.1.7
  • Python: 3.11 (issue also reproduced through the Python wrapper)

Description

I encountered a segmentation fault during the output-writing stage of SU2. The solver itself converges successfully and writes the solution files, but crashes immediately afterward.

Initially I observed this with my own case, but I was also able to reproduce the same behavior using an official SU2 tutorial, indicating that the issue is not case-specific.

Observed behavior

The simulation:

  • converges successfully,
  • writes the output files (restart_flow.dat, flow.vtu, etc.),
  • then terminates with a segmentation fault.

A GDB backtrace consistently points to

PMPI_File_close()

called from

CParallelFileWriter::OpenMPIFile()

through

CSU2BinaryFileWriter::WriteData()
COutput::WriteToFile()

Investigation

While debugging, I traced the issue to the error-handling path in

SU2_CFD/src/output/filewriter/CParallelFileWriter.cpp

which contains logic equivalent to

MPI_File_open(...);

if (ierr != MPI_SUCCESS) {
    MPI_File_close(&fhw);
    ...
}

As an experiment, I removed the MPI_File_close(&fhw) call from this error path, rebuilt both

  • SU2_CFD
  • _pysu2.so

and repeated the tests.

After rebuilding:

  • the official SU2 tutorial completed successfully,
  • my own case completed successfully,
  • the Python interface (pysu2) also completed successfully,
  • I was no longer able to reproduce the segmentation fault.

Notes

At this stage, I cannot conclude that removing MPI_File_close() is the correct fix. However, the experiments consistently indicate that the crash originates from this code path.

It appears possible that the error-handling branch may be attempting to close an invalid MPI file handle, but I would appreciate confirmation from the maintainers regarding whether this interpretation is correct.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions