[LLDB] lldb-mi debugger not able to take input file as an exe argument

[echosys]

Hi, I am trying to debug a program which takes a input file. It works in command line when I run it as ./a.out <testinput.txt and when I try to debug it I get the following output and debugger hangs as if it doesnot get any input.

Launching: '/Users/wge/Github/CSE340cpp/Pj3/a.out'
Working directory: '/Users/wge/Github/CSE340cpp/Pj3'
2 arguments:
argv[0] = '/Users/wge/Github/CSE340cpp/Pj3/a.out'
argv[1] = '<testa8t.txt'

I did try put < and testfile.txt in two arguments with no difference.
I set the external console to be true but it doesn't seem like there is a way for cpp debugger to accept a input like regular command line would?
I am using vscode 1.17 and lastest cpp extension with lldb on Mac OSX.

{
"version": "0.2.0",
"configurations": [
{
"name": "(lldb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/a.out",
"args": ["<testa8t.txt"],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"osx": {
"MIMode": "lldb"
}
}
]
}

[pieandcakes]

@echosys Can you pass an input file like that when using gdb to debug it? I suspect you can't since < is a bash redirect of stdin from a file.

[pieandcakes]

Nope. Looks like I'm wrong. You can add items to args for it. I did:

"args": [ "<", "test.txt" ]

The file needs to sit in your cwd or have the full path to it.

if you enable "logging": { "engineLogging": true" } you can see that we pass it in using -exec-arguments < test.txt and during the -exec-run call it will read it in. If you spell the file name wrong or it can't find it, you should see a failure after -exec-run is called to start the program.

I referred to this article.

[pieandcakes]

I set the external console to be true but it doesn't seem like there is a way for cpp debugger to accept a input like regular command line would?

If externalConsole is true, you can do entry for stdin in the external console window that opens up when debugging starts.

[echosys]

I tried your first suggestion where I use the arg parameter. But it does not work as if the debugger is still waiting for input.
no change when I try "args": [ "<", "test.txt" ] . vs "args": [ "< test.txt" ]

Launching: '/Users/wge/Github/CSE340cpp/Pj3/a.out'
Working directory: '/Users/wge/Github/CSE340cpp/Pj3'
2 arguments:
argv[0] = '/Users/wge/Github/CSE340cpp/Pj3/a.out'
argv[1] = '<testa8t.txt'

[program hangs here....]

[echosys]

On your second remark, I assume you mean input using the console window that opens up? The program still hangs and it seems like the debugger is able to get any input.
I tried using relative and absolute path.

Launching: '/Users/wge/Github/CSE340cpp/Pj3/a.out'
Working directory: '/Users/wge/Github/CSE340cpp/Pj3'
2 arguments:
argv[0] = '/Users/wge/Github/CSE340cpp/Pj3/a.out'
argv[1] = '<testa7C1.txt'
<testa7C1.txt

</Users/wge/Github/CSE340cpp/Pj3/testa7C1.txt
"testa7C1.txt"

[spinicist]

I'm having the same problem as @echosys on a Mac. Both for externalConsole set to true and false, my program hangs, waiting for input when it tries to read stdin.

If you look at @echosys post above, with externalConsole set to true you can see that the argv array is being built incorrectly, with the < file.txt added to the arguments instead of being processed separately. I see the same behaviour.

[dmytro-y-dev]

@pieandcakes thanks for hint! With "args": ["<", "input.txt"] I was able to stream file into stdin on Linux, gdb 7.11.1.

[mmatiush]

The same issue on MacOS HighSierra 10.13.3 (17D102) and VS code Version 1.18.1 (1.18.1).
All just as described by @spinicist

It looks like the problem is because when the program and args from launch.json are launched, they are taken in quotation marks. Let me show in on the example.

My program mmatiush.filler

int		main(int ac, char **av)
{
	printf("%s\n", av[1]);
}

Different output when '<test.txt' is taken in quotation marks and when it's not.

[filler]: '/Users/mmatiush/gitfolder/filler/mmatiush.filler' '<test.txt'
<test.txt
[filler]: '/Users/mmatiush/gitfolder/filler/mmatiush.filler' <test.txt
(null)

The same happens when I try to debug a program that expects stdin input. "<test.txt" redirect doesn't work and console is stuck waiting for my input. On the last line of the screenshot you can see that av[1] is printed as <text.txt while it should be printed as (null) if < worked correctly.

My launch.json

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "(lldb) Launch",
			"type": "cppdbg",
			"request": "launch",
			"program": "${workspaceFolder}/mmatiush.filler",
			"args": [ "<test.txt" ],
			"stopAtEntry": false,
			"cwd": "${workspaceFolder}",
			"environment": [],
			"externalConsole": true,
			"MIMode": "lldb"
		}
	]
}

With "args": [ "<", "test.txt" ] . vs "args": [ "< test.txt" ] result is the same

[spinicist]

Hi,

Is there any progress on this issue? I am still experiencing it. It's the only problem I have with the C++ plugin, everything else works great.

[pieandcakes]

@spinicist Are you also using it on Mac? The gdb on Linux fix seems to work, but I haven't had time to investigate it yet on Mac.

Edit: I see your comment above. I'll see if I can take a look at this soon.

[pieandcakes]

So I tested this with lldb-mi on Mac and using -exec-arguments it doesn't seem like theres a way to pass an input file. Sadly this seems like a bug within lldb-mi and not something we can work around.

[spinicist]

Thanks for testing!

That's a shame. If you run lldb from the command-line on Mac, you can pass an input file with the following syntax:

process launch -i input_file.txt -- arg1 arg2 arg3 ... argN

But I guess that isn't terribly helpful for launching with VS Code.

[pieandcakes]

hmm. let me see if theres more documentation available. Unfortunately, lldb hasn't implemented the mi commands completely the same as gdb so determining what works in gdb means it might not work with lldb. I'll see if I can find a workaround but if it looks like its behind another flag we may need to do additional work to expose another property in the launch.json for you to enter.

[graykode]

In Mac OS, using lldb, I solved this problem like this:
setupCommands, text is solving key

lanuch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "args": [
            ],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "osx": {
                "MIMode": "lldb"
            },
            "setupCommands": [
                {
                    "`": "settings set target.input-path ${workspaceFolder}/input.txt"
                }
            ]
        }
    ]
}

[spinicist]

That's a very interesting tip, I will have to try it. Thanks!

[haha454]

In Mac OS, using lldb, I solved this problem like this:
setupCommands, text is solving key

lanuch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "args": [
            ],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "osx": {
                "MIMode": "lldb"
            },
            "setupCommands": [
                {
                    "`": "settings set target.input-path ${workspaceFolder}/input.txt"
                }
            ]
        }
    ]
}

@graykode I think there is typo inside setupComands. The key should be text instead of `, but anyway thanks for the great solution. It works!

[Aspirisha]

This drived me insane for a couple of hours. Turned out the option is renamed from "setupCommands" to "preRunCommands", even though in oficial documentation it is still setupCommands. The only way I was able to find it out to just eyeball using fuzzy search through all the available configuration string keys which popped up with intellisense.

[small-turtle-1]

This drived me insane for a couple of hours. Turned out the option is renamed from "setupCommands" to "preRunCommands", even though in oficial documentation it is still setupCommands. The only way I was able to find it out to just eyeball using fuzzy search through all the available configuration string keys which popped up with intellisense.

I replace preRunCommands with initCommands and that works.

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": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug",
            "program": "${workspaceFolder}/bin/${fileBasenameNoExtension}",
            "args": [],
            "cwd": "${workspaceFolder}",
            "preLaunchTask": "build",
            "initCommands": [
                "settings set target.input-path ${workspaceFolder}/data/input.txt",
                "settings set target.output-path ${workspaceFolder}/data/output.txt"
            ],
        },
    ],
}

[Aspirisha]

Wow. Just wow! Why are there even more than one way to do it? :)

[Mistobaan]

I lost couple of hours too trying to figure out why the ldb server wasn't picking up the args.
How I solved was :

1. enable engine logging

      "type": "cppdbg",
      "logging": {
        "engineLogging": true,
        }

2. Spelunking the "Debug Console" Tab in VsCode:

1: (312) <-1007-exec-arguments -ngl 35 -m neuralbeagle14-7b.Q4_K_M.gguf --seed 32 --color -c 32768 --temp 0.7 --repeat_penalty 1.1 -n -1 -p "<|im_start|>system
you are a helpful assistant<|im_end|>
<|im_start|>user
{prompt}<|im_end|>
<|im_start|>assistant"
1: (312) ->1007^done
1: (312) ->(gdb)
1: (312) 1007: elapsed time 0
1: (312) <-1008-break-insert -f main
1: (312) ->&"error: 'you' is not a valid command.\n"

Where I realized that:

1. args are sent to the debugger as exec args
2. everything fails silently by default which is BAD. Ideally there should be a settings that detects that &"error:"

how I am solving currently:
manually settings the --exec-arguments:

            {
              "description": "Set exec arguments",
              "text": "-exec-arguments -ngl 35 -m neuralbeagle14-7b.Q4_K_M.gguf --seed 32 --color -c 32768 --temp 0.7 --repeat_penalty 1.1 -n -1 -p ${input:prompt}",
              "ignoreFailures": false,
            }
        ],
      },
    }
  ],
  "inputs": [
    {
      "description": "configure args",
      "id": "prompt",
      "type": "promptString",
      "default": "hello world",
    }

but is hacking and I don't like having that big args string, could be better if I could pass an array .
Any ideas on how to improve this workflow is appreciated.