Specifying arguments in a launch configuration, breaks debugging

[bytorbrynden]

Greetings. I recently tried to create a debug configuration, one with GDB, and another with LLDB, neither worked...

GDB

No errors printed out in Debug Console, and no error popups shown.

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "gdb",
            "request": "launch",
            "preLaunchTask": "exifextract_all",
            "cwd": "${workspaceRoot}",
            "target": "./Build/Final/exifextract",
            "arguments": "./Test/IMG_0985.JPG ./Test/IMG_1351.JPG ./Test/IMG_1353.JPG ./Test/IMG_1355.JPG ./Test/IMG_1357.JPG"
        }
    ]
}

LLDB (using lldb-mi)

No errors in Debug Console. One error popup shown...:

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "lldb-mi",
            "request": "launch",
            "preLaunchTask": "exifextract_all",
            "cwd": "${workspaceRoot}",
            "target": "./Build/Final/exifextract",
            "arguments": "./Test/IMG_0985.JPG ./Test/IMG_1351.JPG ./Test/IMG_1353.JPG ./Test/IMG_1355.JPG ./Test/IMG_1357.JPG"
        }
    ]
}

It's worth noting that, when using the GDB configuration, my executable doesn't appear to ever be launched. However, when using the LLDB configuration, my executable is launched, but terminated almost immediately.

It's also worth noting that my executable runs just fine from the command-line.

I've reviewed issues #37 and #59 (as well as #60, it's duplicate), but neither were of any help to me.

Both GDB and LLDB work fine from the console, and the versions of both, meet the requirements (7.7.1 for GDB, 3.7.1 for LLDB).

Specs:

• OS X 10.11.5
• Visual Studio Code v1.2.0
• Code Debug v0.8.1

Edit: As pointed out in a later comment, when I removed the arguments property from my launch configuration(s), they work fine.

[bytorbrynden]

...another thing I'd like to mention, is that debugging with GDB and LLDB both worked fine not very long ago, as I started using them as part of my development workflow for Glang.

Of course, now that I'm working on a project that has a deadline (which happens to be later today), stuff is going to not-work. Das ist nicht gut...

[WebFreak001]

do you have a .gdbinit file? Remove or rename it if you have. Is gdb callable from the console? If not, fix that first. Does the exifextract_all task exist and work without crashing? Still try running it without that task and ensure it also crashes without that task.

[bytorbrynden]

No, I don't have a .gdbinit file anywhere in my home directory (searched using find ~ -type f -name ".gdbinit"). As my original comment states, "both GDB and LLDB work fine from the console".

Yes, the exifextract_all task exists, and runs without a problem. Removing it from the preLaunchTask doesn't change anything.

[bytorbrynden]

...out of curiosity, I decided to remove the arguments property from my launch configuration, and everything worked just fine.

Problem is, I need to pass at least 1 argument to my program, otherwise it's useless.

[bytorbrynden]

Alright, so, code-debug doesn't like something about any of the following strings:

"Test/IMG_0985.JPG Test/IMG_1351.JPG Test/IMG_1353.JPG Test/IMG_1355.JPG Test/IMG_1357.JPG"
"./Test/IMG_0985.JPG ./Test/IMG_1351.JPG ./Test/IMG_1353.JPG ./Test/IMG_1355.JPG ./Test/IMG_1357.JPG

When the arguments property exists, but is empty (""), everything works as expected.

[WebFreak001]

hm maybe it's the /, does it work if you just provide a few files without any folder?

[bytorbrynden]

That's what I thought too @WebFreak001, however, I tried it (I passed README.md). It didn't give me an error. I then tried it with slashes (Test/README.md), and it still worked.

It's not liking something about the IMG_*.JPG arguments.

• I tried removing the underscores, it still didn't work.
• I tried removing the numbers from the filename, it still didn't work.
• I tried converting the entire filename from uppercase, to lowercase, and it still didn't work.

[bytorbrynden]

So here's something weird; if I pass an argument that's the path to a file that doesn't exist, everything works fine, but if the file exists, the debug adapter terminates unexpectedly...

[WebFreak001]

are you sure its not your program? That doesn't sound like a bug that would get caused by code-debug or gdb

[bytorbrynden]

...it's not my program, because if it was my program, why on earth wouldn't it work if I passed it valid arguments?

I too am confused as to why this happens, since neither code-debug or GDB/LLDB should be doing anything with arguments that I provide... If you don't believe me, I'll boot up a livestream really quick, and show you.

[WebFreak001]

Does it work if you change your arguments to this:

"arguments": "\"./Test/IMG_0985.JPG ./Test/IMG_1351.JPG ./Test/IMG_1353.JPG ./Test/IMG_1355.JPG ./Test/IMG_1357.JPG\""

[bytorbrynden]

Yes, it at least passes an argument to my program, but only one, since the OS is going to treat arguments that are surrounded with ", as a single argument...

[bytorbrynden]

To correct a previous statement that I think I made, the program is started, and an argument does get passed to it, but then the program gets terminated.

When I pass the exact same arguments to the program via the command-line, it works perfectly fine.

[bytorbrynden]

@WebFreak001, I'm about to blow your mind, again. Apparently something, somewhere, doesn't like non-text files.

I created plain-text file in my "Test" directory, and passed the path to it, as an argument, in my launch configuration, and it worked just fine. I then tried passing one of my JPEG files to it, and it died, again.

[WebFreak001]

are you sure it's not your program? If you use a blank hello world program, which doesn't use the arguments, will it work?

[bytorbrynden]

I don't know how it could be my program. When I pass arguments to my program via the command-line, it works just fine. When I pass arguments to my program via a launch configuration in Visual Studio Code, stuff breaks.

Unless something, somewhere, is screwing with the arguments that are getting passed, I see no reason for my program to act so strangely when launched from Visual Studio Code, can you?

[WebFreak001]

code-debug only runs -exec-arguments <the raw argument string from the json file> before executing the program, no fancy conversions happening

[bytorbrynden]

I figured as much. If I remove a call to one of my functions (IE. I don't try and read the contents of the file that was passed to me), the debug adapter doesn't have a problem. My program knows how to deal with files that don't exist, therefore if I pass the path to a file that doesn't exist, it'll ignore it, and proceed to the next argument.

What's really confusing me, is the fact that everything works perfectly fine from the command-line.

[WebFreak001]

Could it be the working directory?

[bytorbrynden]

cwd is set to ${workspaceRoot}, which is /Users/Brynden/code/JPEGMetaExtractor/. The tree goes as follows:

.
├── Build
│   ├── Final
│   │   └── exifextract
│   └── Objects
│       ├── ImageMetadata.src.o
│       ├── MetadataExtractor.src.o
│       └── entry.src.o
├── Include
│   ├── ExifTypes.h
│   ├── ImageMetadata.h
│   └── MetadataExtractor.h
├── Makefile
├── README.md
├── Source
│   ├── ImageMetadata.c
│   ├── MetadataExtractor.c
│   └── entry.c
└── Test
    ├── Driveway1.jpg
    ├── Rascal1.jpg
    ├── Rascal2.jpg
    ├── Road1.jpg
    ├── Road2.jpg
    └── test.txt

6 directories, 18 files

All relative paths, have been checked, double-checked, and checked once more. They are all valid, and point to the correct files.

Yes, I've tried setting the cwd to an absolute path to the project's directory. Nothing changed.

[bytorbrynden]

Alright, apparently there is a problem with my program, somewhere, the debugger is picking up on it, but it doesn't show up in "production".

I'm going to go ahead and close this, because this isn't at all related to code-debug.

Thanks for all the help, Jan, I appreciate it. My apologies for fighting you on the fact that this problem was caused by my program.