Skip to content

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

Open
@Alberto-o

Description

@Alberto-o

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
Image

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

Image

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugdebuggerhelp wantedCan be fixed in the public (open source) repo.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions