Unexpected token ... in JSON at position ...

[dirkseidel]

I am using debugging by attaching to a remote program with the following entries in launch.json:

{
"name": "Debug Remote",
"type": "cppdbg",
"request": "attach",
"program": "...",
"processId": "${command:pickRemoteProcess}",
"sourceFileMap": {
"...": "..."
},
"pipeTransport": {
"pipeCwd": "/usr/bin",
"pipeProgram": "/usr/bin/ssh",
"pipeArgs": [
"..."
],
"debuggerPath": "/usr/bin/gdb"
},
"osx": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
}

After starting debugging, gdb attaches to the program, but shortly after displaying the stack trace, the debugger crashes with error messages like:
"Unexpected token C in JSON at position 2110. Der Debugadapter wird beendet."
Sometimes the token is empty and sometimes it is something different than "C". Also the position is always different. The number of those messages per start ranges from 1 to 5.

I always had this problem every once in a while, but after two or three restarts of debugging I could use it. Unfortunately, since the latest update to version 0.14.4, I have not been able to attach successfully to the program.

[pieandcakes]

@dirkseidel Can you verify the file encoding of your launch.json ? Also, can you see if #1339's problem is similar and try the beta build attached there?

[dirkseidel]

Unfortunately the fix for #1339 does not help here (and also doesn't seem to be related).

Concerning the file encoding I get the following:
src> enca .vscode/launch.json
enca: Language 'de' is unknown or not supported.
Run 'enca --list languages' to get list of supported languages.
Run 'enca -L none' to test only language independent, multibyte encodings.
src> enca -L none .vscode/launch.json
7bit ASCII characters

I am running VS Code on a Mac and the remote debugging takes place with gdb on a Linux machine with SUSE Linux Enterprise Desktop 12 SP2 (x86_64).

How do I get the stacktrace.txt file like in #1339?

[WardenGnaw]

@dirkseidel You can get a similar logs by adding this to your launch.json

"logging": {
   "engineLogging": true
}

[dirkseidel]

I have switched on engineLogging, trace and traceResponse.
In the latest call I got 5 error messages:
Unexpected token in JSON at position 7885.
Unexpected token in JSON at position 7159.
Unexpected token n in JSON at position 3873.
Unexpected token in JSON at position 6305.
Unexpected token n in JSON at position 2995.
Unfortunately the largest JSON appearing in the log output is around 3000 bytes long...

In addition, I also once got the following error message before the debugger aborted:
Unexpected end of JSON input.

[pieandcakes]

@dirkseidel You can probably turn off engineLogging and just do trace/traceResponse. Json parsing is done for communication between our extension and VSCode so either we are sending invalid data or VSCode is. I'd like to see why the data is bad. Can you try and change the encoding for the launch.json to en and see if it still has a problem? I'm wondering if the fact that enca launch.json is coming back as 'de' is a problem.

[dirkseidel]

language `en' is also unknown/not supported on my system.
enca -L none .vscode/launch.json gives
7bit ASCII characters

I have attached the log file
vscodeDebug.log
which corresponds to the following messages:
Unexpected token in JSON at position 8060.
Unexpected token in JSON at position 2844.
Unexpected token in JSON at position 4607.

The unexpected tokens all seem to be new lines in this case.

[pieandcakes]

@dirkseidel that helped figure out what the problem is. It looks like gdb is sending the \n newline character and that is causing the parsing issue on VS Code's side. This bug that I found tells me it is not valid JSON.

I'll take a look and see if this is something we can fix. Since I can't duplicate it, can you send me a log with the same scenario but with just engineLogging enabled?

[WardenGnaw]

@dirkseidel I am having trouble reproducing this issue.

Can you reproduce the issue with running a simple project that has an infinite loop printing "Hello World" on the Linux box and attaching to it?

[dirkseidel]

@pieandcakes vscodeDebug.log
This file corresponds to the messages:
Unexpected token in JSON at position 7583.
Unexpected token i in JSON at position 4058.

It is not always a problem with a newline. In the second message here it is the token "i" and very often it is "C" which is the problem

@WardenGnaw The simple "Hello World" doesn't cause any problems.

[pieandcakes]

@dirkseidel How are you able to determine which characters they are? Also, I don't see those errors in either of the log files you provided. Our debug adapter only sends JSON from the adapter to VS Code, so knowing what we are sending to see this error would be helpful. By going through both logs, my assumption was the '\n' character which seems to be an invalid assumption. Are you sure this JSON error is coming from our code and not your application? I see that in your debug log, that gdb is loading a json parser also.

[dirkseidel]

A popup from VSCode appears at the top of the window stating "Fehler" in red and then the error message like:
"Unexpected token
in JSON at position 5733. Der Debugadapter wird beendet."

The new line only shows up when pasting it in here. In the popup window it is one line and the newline looks like a whitespace character.
I always assumed that the error was thrown by cpptools but I was also wondering why it didn't show up in the logs.

[pieandcakes]

@dirkseidel can you peek in the output window and see if there is a more detailed message?

[dirkseidel]

As far as I can see there is nothing to peek in. Only the message I posted already. The only thing I can do is close it with ESC or click on "Schließen" on the right of the window.

[pieandcakes]

Interesting. Do these messages get preceeded by any specific command or action that you have done? That might be our deserialization of JSON from VS Code then. Do you have any non-English characters (umlaut, ß, etc) in any of your locals or watch variables? I'm trying to figure out how I can reproduce this from my side to debug it.

[dirkseidel]

I just start the debugger with e.g. F5 and then wait. Most of the time the debugger crashes shortly after the stack trace is shown. All our variables are usually in English but of course I don't know if this is true for the whole code.

[aowrew-fp]

Hello, I'm also having an issue with the debugger. I'm on Debian sid with latest updates applied.

After hitting F5, generating the launch json file and updating the paths, the task fails with a message:

Unexpected token { in JSON at position 8. Stopping the debug adapter.

My launch.json contents:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/${fileBasenameNoExtension}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "logging": {
                "engineLogging": true
            }
        }
    ]
}

The debug console only shows:

1: (185) LaunchOptions<LocalLaunchOptions xmlns='http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014'
1: (197) LaunchOptions  ExePath='/home/alex/Documents/szkola/pk/lab1'
1: (197) LaunchOptions  WorkingDirectory='/home/alex/Documents/szkola/pk'
1: (197) LaunchOptions  ExeArguments=''
1: (197) LaunchOptions MIMode='gdb'
1: (197) LaunchOptions  MIDebuggerPath=''
1: (197) LaunchOptions  WaitDynamicLibLoad='false'
1: (197) LaunchOptions  ExternalConsole='true'
1: (197) LaunchOptions>
1: (197) LaunchOptions    <SetupCommands>
1: (197) LaunchOptions        <Command IgnoreFailures='true' Description='Enable pretty-printing for gdb'>-enable-pretty-printing</Command>
1: (197) LaunchOptions    </SetupCommands>
1: (197) LaunchOptions</LocalLaunchOptions>
1: (295) TempFile=/tmp/Microsoft-MIEngine-fifo-kapbqy8r.fka
1: (295) TempFile=/tmp/Microsoft-MIEngine-fifo-reewcdtn.yos
1: (295) TempFile=/tmp/Microsoft-MIEngine-fifo-sdfvvwas.39h

Is there anything else I can provide to help fix this issue?

[pieandcakes]

@aowrew-fp Can you see if reinstalling the extension fixes your issue? Also, when you installed Deb, which language/locale did you install it with? I haven't seen this on Debian either. We are still trying to reproduce this in house so we can debug it and see where it is failing.

when you get this error above, if you go to the output window for VS Code do you see any information in there about the error?

[aowrew-fp]

@pieandcakes thanks for your reply - I have tried reinstalling the plugin and reloading VSC.
My locale settings are (and I believe those are the ones I've installed with):

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

I've recorded how the error appears, you can see here - https://vimeo.com/259658475

[stanf0rd]

I found a reason of error "Unexpected token { in JSON at position 8." - the new version of gnome-terminal (3.27). After downgrading to version 3.24 from Ubuntu 17.10 no error occures.

[WardenGnaw]

@stanf0rd Thank you for the repro.

It looks like gnome-terminal 3.27 changed behavior of sending their error messages through stdout instead of stderr which is causing the debug adapter to send invalid messages to VsCode.

We think we have a fix and we will create an insiders for it shortly.

[sean-mcmanus]

A fix is available at https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.0-insiders2 . Let us know if there are any issues before our official release some time next week.

[dirkseidel]

Unfortunately, the fix doesn't solve the problem for me. Still getting unexpected token errors.
bash on Mac running VSCode:
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
bash on remote machine running the program to debug:
GNU bash, Version 4.3.42(1)-release (x86_64-suse-linux-gnu)

[aowrew-fp]

@sean-mcmanus the update fixed it for me, many thanks!

[pieandcakes]

@dirkseidel So the issue that we could reproduce on Linux was that the terminal was sending data itself on stdout instead of stderr which VS Code wasn't expecting and our solution was to log it to the engine log. If you enable engine logging with "logging": { "engineLogging": true" } can you see if you see anything there after the LaunchOptions are displayed?

Otherwise, we will need to get some more specific repro steps on Mac.

[WardenGnaw]

@dirkseidel We found another place we did not redirect output. Can you try https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.1 to see if this fixes it for you?

[dirkseidel]

Now everything seems to be fine. Thanks!