I wrote following code
Debug.Listeners.Add(new TextWriterTraceListener(Console.Out));
Debug.AutoFlush = true;
Debug.Indent();
Debug.WriteLine("test");
Nothing is output in output window
What's wrong?
I use debug output in a slightly different way to your example:
Trace.Listeners.Clear();
DefaultTraceListener listener = new DefaultTraceListener();
Trace.Listeners.Add(listener);
Debugger.Log(1, "test", "oops i've crashed");
The debug output does go to the output window. Make sure that you are running as "debug" and not "release"
Also worth checking: right-click in the output window, and ensure "Program output" is checked.
Possible causes that I can think of:
Do you compile the application in DEBUG mode?
Do you run the application while debugging? Visual Studio has to listen to the application, and this is done when you are debugging the application.
Do you configure somewhere debug listeners?
Related
How to specify the path of generated debug binary file when debug go-lang in vs-code?
I have tried modify launch.json file but not work.
I can debug go programs well now in vs-code, the only problem is each time i finish debug, a debug binary file was generated under my project directory, like the picture below.
I want to know can i specify the directory of generated debug binary file?
I am on mac screen shot of my problem:
This is followed by vscode-go issue 1345: "Delete binary files created by delve after closing the debug session"
delve is the debugger for Golang, or at least it's the one that the Go extension uses.
When you debug something with delve, it creates a large binary file in the current directory. If you debug a main function (dlv debug), you get 'debug'. If you debug a test function (dlv test), you get 'debug.test'.
In normal delve usage, when you're done, you quit delve. Delve then deletes this file. Apparently VSCode gracelessly terminates (SIGKILL?) delve, which means the file sticks around.
So this is studied, but not yet resolved.
Update July 2018: Ramya Rao adds in this issue:
I finally have an update!
Turns out there is a command called Detach that can be called on the delve server which will result in the required clean up of the debug binary that gets generated.
To get this fix before the next update to the Go extension (which will be either Friday or early next week), please follow the below:
Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
Run code --install-extension Go-latest.vsix
If the above fails with Error: end of central directory record signature not found, then clone this repo (vsgo) and use the Go-latest.vsix file from the cloned repo
Reload VS Code
The fix worked for me as long as the program being debugged wasn't spawning processes of its own like a web server for which I have logged an upstream issue with delve.
I'd appreciate it if folks here can give the fix a try and share any feedback.
The change you need to do to provide an output path for the generated debug binary is in the launch.json file.
Use the property output in your debug configuration.
Please don't modify the package.json file.
This debug file was generated by delve when debugging and should be deleted after debugging, this seems to be bug of go extension of vs-code, see the link here
I have installed WSL(Ubuntu on Windows) and gcc/gdb, and open a directory in Visual Studio Code, then click Debug Menu | add configuration, select C/C++:(gdb) Bash on
Windows launch, press F5，get the message:
Unable to start debugging, Unable to establish a connection to GDB, ...
output in debug console:
Starting: "C:\Windows\sysnative\bash.exe" "/usr/bin/gdb --interpreter=mi"
"C:\Windows\sysnative\bash.exe" exited with code -1 (0xFFFFFFFF).
I don't have enough points to leave a comment, but could you paste your
configuration in launch.json? One issue I have seen is that "/usr/bin/gdb --interpreter=mi" gets treated as single string instead of calling gdb with an extra flag. Updating my configuration with the following flag in pipeArgs fixed the error for me.
"configurations": [
...,
"pipeTransport": {
"debuggerPath": "/usr/bin/gdb",
...
"pipeArgs"; ["-c"],
}
]
In visual studio code, does launch.json file support "console" option to chose what kind of console to use with GDB, for example, internalConsole, integratedTerminal, externalTerminal?. Today by default application output is directed to external terminal..
launch.json supports the following option:
"externalConsole": true | false
Where:
true: outputs to an external terminal
false: outputs to the internal debug console
I haven't found an option for redirecting to the integrated terminal.
When I start debug in Netbeans, nothig happens. Output strings don't apper; Pause, Continue, step buttons are inactive (only Stop debug button and restart button are active). Stack window is empty.
I tried to run process in shell and attach to it by Netbeans debug. Message with caption "Debugger error" appeared, it contained a text: \320\235\320\265\321\202 \321\202\320\260\320\272\320\276\320\263\320\276 \321\204\320\260\320\271\320\273\320\260 \320\270\320\273\320\270 \320\272\320\260\321\202\320\260\320\273\320\276\320\263\320\260.
Project is compiled with -g flag; gdb version is: GNU gdb 7.0.1-debian; Netbeans version is 7.1; In DDD tool debug for this program works fine.
In my case the cause was a bad variable in the Watches. I couldn't delete it while debugging was hanging. So I had to open the variables window manually while not building/debugging (Windows -> Debugging -> Variables). After deleting the bad variable, everything was fine.
Basically I deleted all variables, since I couldn't figure out, why gdb or netbeans disliked something like:
(char*)_Foo->Bar->Fail. During the previous debugging run this watch worked fine.
I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging