1.23.5: cppdbg stopped working on CentOS 7 and RHEL 7

[kzhdev]

Environment

• OS and version: Mac OS Sequoia 15.3
• VS Code: 1.96.4
• C/C++ extension: 1.23.5
• OS and version of remote machine (if applicable): CentOS Linux 7.3
• GDB / LLDB version: GDB 10.2-6.el7

Bug Summary and Steps to Reproduce

Bug Summary:
cppdbg not launching anymore. When clicked on the green arrow to start the debugger, a clock shows on the debug button on left side bar and disappears right away. There is nothing in the DEBUG CONSOLE and no related log messages anywhere. I don't know exactly what's wrong.

How do I figure out why the debugger doesn't start?

Steps to reproduce:

1. In this environment...
2. With this config...
3. Do '...'
4. See error...

Debugger Configurations

{
            "name": "UnitTest",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/cmake-build-debug/PMGUTestApp",
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "/opt/rh/devtoolset-11/root/usr/bin/gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        },

Debugger Logs

There is no debugger logs

Other Extensions

No response

Additional Information

No response

[sean-mcmanus]

There's also a discussion thread with 2 other users reporting this on CentOS 7 at #13213 (reply in thread) .

[github-actions]

Thank you for reporting this issue. We’ll let you know if we need more information to investigate it. Additionally, if you're working with GDB/LLDB, please note that the code is open source at https://github.com/microsoft/MIEngine/wiki/Contributing-Code . Your contributions are always welcome and appreciated.

[SteveMilesQuant]

I'm seeing a similar issue that started last week, but I'm not on CentOS. I'm on Red Hat 7. Rolling back the the C/C++ extension version gets it to work. I also can't find any logs with any relevant information, even after turning on almost every logging option.

FWIW, my system is pretty old, so maybe it's the GLIB version, as the other comment chain seems to suggest. When I run "/lib/libc.so.6", get the following:
Compiled by GNU CC version 4.8.5 20150623 (Red Hat 4.8.5-44)

[LMBernardo]

+1, I can confirm that 1.23.5 stops working with no apparent error. Projects build and link successfully, then just nothing happens. I don't even get dropped into a debugging console. Reverting to a previous versions restores debugging on the same project.

[bobbrow]

My understanding was that CentOS 7 and RHEL 7 were based on the same (or very similar) kernel, so I believe that is why they have the same issue.

We've talked to the debugger team and we're not certain that we'll be getting a version of the debugger that will work with these OS versions. We were unaware of the switch, but the debugger was updated to use .NET 8 because .NET 6 passed its end of life so we can't release it in our extension anymore. Unfortunately, as part of this update, a higher GLIBC dependency was taken and these OS versions don't support that. Given that CentOS 7 and RHEL 7 are both past the end of their support cycles, right now it looks like it will be unlikely that future versions of the C++ extension will have a working debugger bundled on those OS'es.

I know that this is not what you were hoping to hear, but until we know for sure, you'll need to stay on 1.22.11 if you want a working debugger or start thinking about updating your OS to a newer version (at least 9).

[SteveMilesQuant]

EDIT
Actually, I think RHEL 8 works just fine. My gdb version wasn't compatible with RHEL 8. Once I switch that, I think I was ok.
EDIT

Thanks Bob. My organization is pretty large and old, so the best I have is RHEL 8 right now. When I use that, I get the message:
"error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory"

I'll assume that's in line with RHEL 8 also being too old for this and I'll use the older version of the C/C++ extension until we update to RHEL 9+.

[bradermanhitachirail]

Maintenance support for Red Hat 8 will continue until 2029: https://access.redhat.com/product-life-cycles?product=Red%20Hat%20Enterprise%20Linux,OpenShift%20Container%20Platform%204 . I would hope/expect RHEL 8 to have a recent enough GLIBC to not be such a burden to support. Large organizations do not upgrade OSes very quickly.

[LMBernardo]

For what it's worth - 1.23.5 does work for me on RHEL8 machines with the same projects that were failing on RHEL7.