I'm using Debug.Break() to track down bugs in my code. I want to insert a "Halt" in the Visual Studio IDE so that I can inspect values.
Now I'm in a situation where the IDE just goes over Debug.Break() without stopping:
_lrNavMeshPath = nParentForLineRenderer.gameObject.AddComponent<LineRenderer>();
if (_lrNavMeshPath == null)
{
System.Diagnostics.Debugger.Break();
}
What might be the reason why the IDE just goes over this line without stopping?
I have set a breakpoint at this line, so I see that this line is called.
Thank you.
Related
I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.
Environment: Visual Studio 2017, Windows 10 ver. 1709. Compiling mode: release.
When I call:
accelerator_view acc_view = accelerator().default_view;
an exception is raised (see figure link below), but the code performs fine afterwards.
But when the executable process exits and I call:
::GetExitCodeProcess(hChildProcess, &retVal);
from a caller process, instead of returning 0, it returns a garbage value in retVal.
Digging the source code, the problem seems to be in the snipped code below (SchedulerBase.cpp, line 149)
// Auto-reset event that is not signalled initially
m_hThrottlingEvent = platform::__CreateAutoResetEvent();
// Use a trampoline for UMS
if (!RegisterWaitForSingleObject(&m_hThrottlingWait, m_hThrottlingEvent, SchedulerBase::ThrottlerTrampoline, this, INFINITE, WT_EXECUTEDEFAULT))
{
throw scheduler_resource_allocation_error(HRESULT_FROM_WIN32(GetLastError()));
}
I think it is beyond my hands to fix it, because the code above is inside MFC. The same code works well when compiling with Visual Studio 2013. Refer to the figure attached of the stack, showing the raised exception (and catched inside) when I call
accelerator_view acc_view = accelerator().default_view;
The question: how to clean up the AMP before exiting and the getting the correct result when calling GetExitCodeProcess()?
Here is the figure:
Solved! If you add
concurrency::amp_uninitialize();
after using AMP framework, when the caller process calls
::GetExitCodeProcess(hChildProcess, &retVal);
The retVal parameter is filled correctly.
Since updating Eclipse from Neon to Oxygen I've an issue with the "F6 - Step Over" function while debugging my code. Each time I'll use "Step Over" and the current line contains a method call I'll get into the method (behaviour of "F5 - Step Into"). The same behaviour occurs when using the "Step over" - button. After stepping into the method I lost connection (e. g. when using "F6 - Step Over" again) to the debugger and an error occurs: "com.sun.jdi.InternalException: Got an error code in reply:35 occurred creating step request.".
A typical code line which causes the mentioned problem looks like:
Collection<Object> coll = getSomething(...);
...
...
private Collection<Object> getSomething(...) { ... }
Does anyone have the same issue and can give me a hint how to solve this?
I had the exact same problem and found an answer to your question:
On the page https://www.eclipse.org/eclipse/news/4.7/jdt.php#step-show-methodresult they introduced this new feature.
If you disable it, Step Over will work as always ;-)
go to Window - Preferences - Java - Debug and disable "Show method result after a step operation (if supported by the VM; may be slow"
Why they enabled an experimental feature that disastrous is anyones guess...
I'm currently trying to write an VS Code extension and it's a bit frustrating. I did everything as said here:
https://code.visualstudio.com/docs/extensions/example-hello-world
But after using yo code and entering all necessary information, I opened the respective folder VS Code hit F5 and VS Code says I should configure my launch.json (this should be done by yo code, shouldn't it?). However, when I press the debug start button, a extension-host window opens as described in that tutorial. BUT: When I try to execute the extension the command palette won't find it.
I tried several command names such as "hello world" "helloworld" or variants of the name of the extension that I gave in yo code. I also noticed the
"commands": [{
"command":"extension.sayHello",
"title":"Hello World"
}]
section of the package.json, but somehow I don't manage it to put it all together in order to get a simple, working vs code extension. In tutorial videos on youtube everyone can simply hit F5 after launching VS Code, what I cannot. Pretty weird somehow.
Any help is appreciated!
Thanks in advance.
EDIT: Additional information.
When I activated vs code to show all exceptions (even handled) vs code stops at the following point (see default:)
at internal/process/stdio.js (core module)
// ...
case 'PIPE':
case 'TCP':
var net = require('net');
stream = new net.Socket({
fd: fd,
readable: false,
writable: true
});
stream._type = 'pipe';
break;
default:
// VS CODE STOPS AT THE LINE FOLLOWING!
// Probably an error on in uv_guess_handle()
throw new Error('Implement me. Unknown stream file type!');
}
// Ignore stream errors.stream.on('error', function() {});
} catch (error) {
stream = createDevNull();
}
//...
Hopefully it helps :(
I solved my problem by reading the tutorial with more attention. The tutorial tells you to activate the command palette by Hitting F1 not CTRL P. This solved my Problem.
I did not change anything in the code; rather it seems to be important to hit F1 instad of [CTRL] + [P] despite it actually brings up the same input. I'm still wondering why to differenciate between CTRL + P and F1 if both bring up the same control. :/
Hope it helps other beginners, too.
cheers!
I had the same issue (though didn't debug to see if it failed on the same line) and I resolved it by restarting VSCode.
For assert macros in my iPhone project, I'm looking for a way to programmatically break into the debugger. On Windows (MSVC++), I can use __debugbreak() for this purpose. Invoking this function will stop my program, launch the debugger, and display a callstack of the line that called __debugbreak().
Is there anything similar to __debugbreak() for the iPhone? I've tried Debugger(), but that gives me a linker error.
Thanks,
Claus
edit
Turns out this also works:
#define Debugger() { raise( SIGINT ) ; }
I think it's the same principle.
I use this:
#define Debugger() { kill( getpid(), SIGINT ) ; }
I think it works
in the simulator and on the device.. no assembly required!
A helpful person on Apple's developer forum gave me the tip to use asm("trap") when running on the device and asm("int3") when running on the simulator. This makes the program break into the debugger if you started your programm in debug mode (Option-Command-Y).
(__builtin_trap() also breaks into the debugger, but you can't continue afterwards. assert(false) terminates the program with a message, but doesn't break into the debugger.)
First Add -DDEBUG to OTHER_CFLAGS on your debug target; this will define the DEBUG symbol when building a debug build.
Then add a simple assert macro to your prefix header:
#ifdef DEBUG
#define MyAssert(val) _MyAssert(val)
#else
#define MyAssert(val) do { } while(0)
#endif
Next create a _MyAssert function in a module somewhere:
#ifdef DEBUG
void _MyAssert(int expression)
{
if (expression == 0) {
NSLog(#"Assertion failed!"); // Place breakpoint here
}
}
#endif
Finally create a breakpoint on the NSLog line.
I just set a breakpoint at the place I want to stop. Xcode remembers breakpoints persistently, so any time I run the app with gdb, it'll stop at that point.
If you want to break on assertion failures, a good place to set a breakpoint is on the function objc_exception_throw, in the Objective-C runtime, which is what actually throws an exception. Use the Run > Show > Breakpoints window and double-click the "Double-click for symbol" row, then type the name.
Is there something wrong with the simple assert() macro? Something like
assert(pointerToTest != nil);
will halt your process at that point if the condition is not true. If running under the debugger, you'll be presented with a stack trace of calls that led to the failed assertion. If you want to trigger it every time you hit a certain code path, you could do
assert(false);
I find these assertions extremely useful for verifying that all IBOutlets are non-nil when a window or view is brought up from a NIB.
If you run your program in debug, your app should launch the debugger when it reaches an invalid assertion.
For it to stop, as Jens Alfke tried to say, you need to enable "Stop on Objective-C Exceptions" (under the Run menu).
For more info about debugging vs. releasing and asserts, read http://myok12.wordpress.com/2010/10/10/to-use-or-not-to-use-assertions/
While an ancient thread, found this while researching same topic for Xcode 7. What solved this for me was a feature called "Create Exception Breakpoint..."
Debug > Breakpoints > Create Exception Breakpoint...
This puts a special breakpoint in the Breakpoint Navigator (under View > Navigators > Show Breakpoint Navigator).
This breaks on the actual throw of the exception:
[ exception raise ]
without terminating your code execution. You can just continue if that is how your code is structured.
Double-clicking the break point marker next to "All Exception" lets you adjust where and how the exception break point stops:
Check out conditional breakpoints:
http://www.cocoabuilder.com/archive/message/xcode/2008/10/22/25358