microsoft / microsoft/vscode-cpptools

the debugger gets confused on same named structs that defined in separate c modules

Open
#6,352 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

debugger more info needed
Dominant language
TypeScript
Stars
6.2k
Forks
1.7k
Avg merge
14h 46m
Merged PRs (30d)
61

Description

Type: Debugger

Describe the bug

  • OS and Version: Windows 10 (10.0.19041)
  • VS Code Version: 1.50.1 (user setup)
  • C/C++ Extension Version: v1.0.1
  • Other extensions you installed (and if the issue persists after disabling them): ARM (Syntax Highligter), CMake, Cmake Tools, Go, Python, x86 and x86_64 Assembly (Syntax highligther)
  • A clear and concise description of what the bug is.

The debugger does not map correct type info for identical named structs that has different fields on separate c modules.

Steps to Reproduce:

  1. Create two C files for example file1.c and file2.c
  2. Define a struct in each c file with identical name but different fields. for example

in file1.c

typedef struct _hey
{
    char chrarr[60];
    int intval;
}hey;

in file2.c

typedef struct _hey
{
    char chrarr[20];
    int intval;
    int a;
    int b;
}hey;

As you know, these types are not exported outside of the module, so these types are internal and isolated from each other.

  1. create an instance of second type of "hey". put some breakpoint to examine struct's data

  2. when breakpoint hit, add the variable into watch window or just type into debugger console.

Expected result: debugger should have mapped and displayed file2.c's hey type.
Experienced result: debugger maps and shows the data using file1.c's "hey" type instead of file2.c's

Ps: If the issue could not reproduce please try to create an instance for first one. Because I'm not sure that which type have been chosen by the vscode.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue with the two example modules, file1.c and file2.c, defining separate same-named structs. Start by placing a breakpoint on an instance from file2.c and inspect it in the watch window or debugger console. Done means the debugger displays file2.c's fields and values using the correct type rather than file1.c's definition.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.