gdb attaching to mpi process unable to retrieve stack trace and variables

Environment

• OS and version: Microsoft Windows 10 Pro. Version 10.0.19045 Build 19045
• VS Code: 1.99.3
• C/C++ extension: 1.25.3
• OS and version of remote machine (if applicable): WSL Ubuntu 22-04
• GDB / LLDB version: gdb 16.3

Bug Summary and Steps to Reproduce

Bug Summary: I'm using mpirun to run a fortran program, and once it is executing I attach to one of the processors using gdb. I have a series of breakpoints. At the entry point of the program, gdb hits the breakpoint and vscode shows it successfully. When entering a particular subruotine the strange behaviour apperars: gdb stops, but vscode does not focus on the breakpoint, the variables are not accessible, and the call stack shows the message "Unable to retrieve stack trace. The message is improperly formatted or was damaged in transit". I know gb has stopped because I'm monitoring the program execution on another terminal, and also because the "pause" symbol in the debugger control buttons has changed to "continue".

With respect to the routine: there is a breakpoint when the subroutine is called, and another one inside the subroutine definition. vscode stops correctly at the former, it's the latter where the problem appers.

This behavior was not present in gdb version 12.1, but apperars in versions 15.1 and 16.3

At the last "visible" breakpoint, the vscode window looks like

At the breakpoint which is hit but now shown (variables unresponsive, stack trace not shows, no focus on breakpoint)

Debugger Configurations

launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
        "name": "(gdb) Attach",
        "type": "cppdbg",
        "request": "attach",
        "processId": "${command:pickProcess}",
        "program": "${workspaceFolder}/build/bin/semba-fdtd",
        "miDebuggerPath": "/usr/local/bin/gdb",
        "MIMode": "gdb",
        "logging": {"engineLogging": true, 
                    "exceptions": true, 
                    "moduleLoad": true, 
                    "natvisDiagnostics":true, 
                    "programOutput": true, 
                    "trace": true, 
                    "traceResponse": true
        },
        "setupCommands": [
            {
                "description": "Enable pretty-printing for gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true
            },
            {
                "description": "Set Disassembly Flavor to Intel",
                "text": "-gdb-set disassembly-flavor intel",
                "ignoreFailures": true
            }
        ]
    },
  ]
}

Debugger Logs

Debugger logs are too long. They have been included as attached files.

Other Extensions

No response

Additional Information

The full debugger output (until the manual interruption after the problematic breapoint) is attached here
stack.txt
The debugger output generated between the last proper breakpoint, and the breakpoint where the info is missing, is here reduced_stack.txt

There's n error message that I think points to a potential cause:
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (12957) ->1317^error,msg=\"Lower bound may not be '*' in F77\"\n"},"seq":3606} 1: (12957) ->1317^error,msg="Lower bound may not be '*' in F77"

The problem persists even if I run mpirun with just one process, but disapperars if I execute the program not using mpirun.

My .gdbinit file looks like:

set max-value-size unlimited
set print elements 0

Start with the attached reduced_stack.txt and stack.txt logs, then review launch.json and .gdbinit. Compare the reported behavior across GDB 12.1, 15.1, and 16.3, including the “Lower bound may not be '*' in F77” error and the mpirun setup. Done means the problematic breakpoint presents the call stack, variables, and source focus in VS Code.