Skip to content

Debugger hangs starting gdb.exe on Windows 10 with UTF-8 enabled. #1527

Closed
microsoft/MIEngine
#942
@weinand

Description

@weinand

From @leoliuasia on February 7, 2018 6:6

  • VSCode Version:1.19.3
  • OS Version: Windows 10 Pro 1709 16299.214

Steps to Reproduce:

  1. Debug->Start Debugging
  2. Nothing happens.... just hang in there with little blue block progressbar scrolling...

But when I force end task for gdb.exe in task manager window, vscode shows up an error, and little blue block disappears.

c_cpp_properties.json:

{
            "name": "Win32",
            "includePath": [
                "${workspaceRoot}",
                "C:\\MinGW\\lib\\gcc\\mingw32\\6.3.0\\include\\c++"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE"
            ],
            "intelliSenseMode": "msvc-x64",
            "browse": {
                "path": [
                    "${workspaceRoot}",
                    "C:\\MinGW\\lib\\gcc\\mingw32\\6.3.0\\include\\c++"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            }
        }

task.json:

"tasks": [
        {
            "label": "build cpp",
            "type": "shell",
            "command": "g++",
            "args": [
                "-g",
                "-o",
                "a.out",
                "main.cpp",
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]

launch.json

"configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}\\a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]

Copied from original issue: microsoft/vscode#43075

Activity

pieandcakes

pieandcakes commented on Feb 7, 2018

@pieandcakes
Contributor

@leoliuasia Can you enable "logging": { "engineLogging": true } and see where it stops while communicating with gdb?

leoliuasia

leoliuasia commented on Feb 8, 2018

@leoliuasia

@pieandcakes Thanks for your time! Below are the output informations from the DEBUG CONSOLE after logging enabled.

  • 1: (267) LaunchOptions<LocalLaunchOptions xmlns='http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014'
  • 1: (283) LaunchOptions ExePath='c:\Users\Leo\Desktop\cpp\a.out'
  • 1: (283) LaunchOptions WorkingDirectory='c:\Users\Leo\Desktop\cpp'
  • 1: (283) LaunchOptions ExeArguments=''
  • 1: (283) LaunchOptions MIMode='gdb'
  • 1: (283) LaunchOptions MIDebuggerPath='C:\MinGW\bin\gdb.exe'
  • 1: (283) LaunchOptions WaitDynamicLibLoad='false'
  • 1: (283) LaunchOptions ExternalConsole='true'
  • 1: (283) LaunchOptions>
  • 1: (283) LaunchOptions
  • 1: (283) LaunchOptions -enable-pretty-printing
  • 1: (283) LaunchOptions
  • 1: (283) LaunchOptions
  • 1: (361) Starting: "C:\MinGW\bin\gdb.exe" --interpreter=mi
  • 1: (1914) DebuggerPid=9076
  • 1: (1982) ->=thread-group-added,id="i1"
  • 1: (1983) ->~"GNU gdb (GDB) 7.6.1\n"
  • 1: (1983) ->~"Copyright (C) 2013 Free Software Foundation, Inc.\n"
  • 1: (1983) ->~"License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type "show copying"\nand "show warranty" for details.\n"
  • 1: (1983) ->~"This GDB was configured as "mingw32".\nFor bug reporting instructions, please see:\n"
  • 1: (1983) ->~"http://www.gnu.org/software/gdb/bugs/.\n"
  • 1: (1983) ->(gdb)
  • 1: (1992) <-1001-gdb-set target-async on
  • 1: (1992) ->&"\357\273\2771001-gdb-set target-async on\n"
  • 1: (1993) ->&"Undefined command: "\357". Try "help".\n"
  • 1: (1993) ->^error,msg="Undefined command: "\357". Try "help"."
  • 1: (1993) ->(gdb)
  • 1: (1993) ->&"\n"
  • 1: (1993) ->^done
  • 1: (1993) ->(gdb)
leoliuasia

leoliuasia commented on Feb 8, 2018

@leoliuasia

@pieandcakes When this kind of things happens, I think the "Stop Debugging" should also be working, but it does not. The whole debug process only can start again util reopen the vscode.

pieandcakes

pieandcakes commented on Feb 8, 2018

@pieandcakes
Contributor

@leoliuasia I don't know if you are using a different encoding, but for some reason gdb is receiving

1: (1992) <-1001-gdb-set target-async on
1: (1992) ->&"\357\273\2771001-gdb-set target-async on\n"
1: (1993) ->&"Undefined command: "\357". Try "help".\n"
1: (1993) ->^error,msg="Undefined command: "\357". Try "help"."

and the issue looks like ->&"\357\273\2771001-gdb-set target-async on\n" with the strangely escaped characters.

WardenGnaw

WardenGnaw commented on Feb 9, 2018

@WardenGnaw
Member

@leoliuasia Can you run reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage? This will help us understand which language you have enabled on your OS for us to recreate the issue.

leoliuasia

leoliuasia commented on Feb 9, 2018

@leoliuasia

@WardenGnaw Below is the output:

D:\Integration Projects>reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage
HKEY_LOCAL_MACHINE\system\controlset001\control\nls\language
Installlanguage REG_SZ 0409

WardenGnaw

WardenGnaw commented on Feb 9, 2018

@WardenGnaw
Member

Could you also share what CodePage your OS is running? You can find this out by building and running the attached project.

You can build and run this by installing dotnet core at https://www.microsoft.com/net/learn/get-started/windows. Then unzip that project and run dotnet build and dotnet run.

You should see something similar to Your code page is 437 but with a different number.

CheckCodePage.zip

WardenGnaw

WardenGnaw commented on Feb 10, 2018

@WardenGnaw
Member

Hi,

We may have a potential fix. Can you try installing this patched cpptools vsix and see if this fixes your issue?

cpptools.zip

Please uninstall the c/c++ extension that is already installed, then in the Extensions menu, click on the 3 dots and you should see install from vsix.

image

Thank you.

bolu61

bolu61 commented on Feb 12, 2018

@bolu61

@WardenGnaw I ran into the exact same issue. My code page is 65001. The potential fix does not work.
@pieandcakes I believe that \357\273\277 is a BOM indicating UTF-8 encoding?

pieandcakes

pieandcakes commented on Feb 12, 2018

@pieandcakes
Contributor

@MUTTSU which OS installation are you using? Please give the OS version and the locale that you installed so we can setup a proper test machine. We haven't been able to duplicate this issue here yet.

bolu61

bolu61 commented on Feb 12, 2018

@bolu61

Im using win10pro build 17093.1000 (though i had this issue with older builds). Locale is en_CA.

Also I was wondering when the extension starts gdb, where does "set target-async on" come from? I couldn't figure out where in the extension's code it tries to put these configurations.

pieandcakes

pieandcakes commented on Feb 12, 2018

@pieandcakes
Contributor

Do you have any additional language packs installed? are you using an input method other than English?

36 remaining items

phanthaiduong22

phanthaiduong22 commented on Sep 24, 2019

@phanthaiduong22
Member

Actually, I typed a,b (ex: 3 4) in temminal in vscode . but nothing happened.

z7z8th

z7z8th commented on Oct 20, 2019

@z7z8th

This issue blocked me several days until I know it's caused by UTF BOM.
After some debugging, I found that the BOM does not come from the PIPE, but comes from the input stream of the debugger(gdb for me).

In file https://github.com/microsoft/MIEngine/blob/master/src/WindowsDebugLauncher/DebugLauncher.cs :
I think the UTF BOM is already in the BaseStream when creating the debugger process.
So the following line did not remove the BOM.

_debuggerCommandStream = new StreamWriter(_dbgProcess.StandardInput.BaseStream, new UTF8Encoding(encoderShouldEmitUTF8Identifier: false)) { AutoFlush = true };

Two possible solutions:

  1. flush the UTF8 BOM individually:
    Add the following lines after https://github.com/microsoft/MIEngine/blob/ccec0b00986ca4606b19291a3a3fcf986e5728a6/src/WindowsDebugLauncher/DebugLauncher.cs#L135
_debuggerCommandStream.WriteLine();
_debuggerCommandStream.Flush();

Log after this change:

1: (993) ->~"For help, type \"help\".\n"
1: (994) ->~"Type \"apropos word\" to search for commands related to \"word\".\n"
1: (996) ->(gdb)
1: (996) ->&"\357\273\277\n"
1: (996) ->&"Undefined command: \"\".  Try \"help\".\n"
1: (996) ->^error,msg="Undefined command: \"\".  Try \"help\"."
1: (996) ->(gdb)
1: (1000) <-1001-gdb-set target-async on
1: (1005) Send Event AD7MessageEvent
1: (1007) ->1001^done
1: (1007) ->(gdb)
1: (1007) ->&"\n"
1: (1007) ->^done
1: (1007) ->(gdb)
1: (1007) 1001: elapsed time 6
1: (1014) <-1002-enable-pretty-printing
  1. change the encoding of the console of windowsdebugadapter.exe, so the debugger inherits it's settings
    Add the following line before _dbgProcess.Start(); in https://github.com/microsoft/MIEngine/blob/master/src/WindowsDebugLauncher/DebugLauncher.cs
Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Log after this change:

1: (993) ->~"Type \"apropos word\" to search for commands related to \"word\".\n"
1: (995) ->(gdb)
1: (999) <-1001-gdb-set target-async on
1: (1005) ->1001^done
1: (1005) ->(gdb)
1: (1005) ->&"\n"
1: (1005) ->^done
1: (1005) ->(gdb)
1: (1006) 1001: elapsed time 7
1: (1012) <-1002-enable-pretty-printing

I tested the 2nd solution with English+UTF8, Chinese+UTF-8 and Chinese+Unicode(UTF16), all works.

The 2nd solution seems cleaner if no other impact.

phanthaiduong22

phanthaiduong22 commented on Oct 21, 2019

@phanthaiduong22
Member
  1. DebugLauncher.cs

Excuse me, Where is DebugLauncher.cs located in my computer.

Thanks

z7z8th

z7z8th commented on Oct 21, 2019

@z7z8th

@phanthaiduong22
You need to download the MIEngine source code to get that file. It's part of the source code of the c/c++ extension. the source code needed to be built in visual studio to generate windowsdebugadapter.exe and serveral other files. but your problem is not related to this issue.

pieandcakes

pieandcakes commented on Oct 21, 2019

@pieandcakes
Contributor

@z7z8th Thank you for your investigation. Let me take that fix and do some additional testing.

Thanks!

self-assigned this
on Oct 25, 2019
added
fixedCheck the Milestone for the release in which the fix is or will be available.
on Oct 25, 2019
added this to the 0.26.1 milestone on Oct 25, 2019
michelleangela

michelleangela commented on Oct 28, 2019

@michelleangela
Contributor

Fixed in 0.26.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugdebuggerfixedCheck the Milestone for the release in which the fix is or will be available.

Type

No type

Projects

No projects

Relationships

None yet

    Development

    Participants

    @rivy@z7z8th@weinand@WardenGnaw@Iamnvincible

    Issue actions

      Debugger hangs starting gdb.exe on Windows 10 with UTF-8 enabled. · Issue #1527 · microsoft/vscode-cpptools