While debugging, if (and only if) i have a break point in my node destructor i get this screen saying:
Source Not Available
Source information is missing from the debug information for this module.
You can view disassembly in the Disassembly window. To always view disassembly for missing source files, change the setting in the Options dialog.
(Here is a picture of the whole screen)
I've looked everywhere on the net and the only "solution" i've found is moving the breakpoint which is not a real solution,
What can i do to fix the issue? Thanks.
(Windows 8.1, Visual Studio 2013)
Here is the code of the destructor which is one step before the screen appears:
MatchmakingAgency::Node::~Node(){
cout << "Deleting: ";
getClient()->printName();
cout << endl;
if (next){
delete next;
}
}
As written in the comments you're stepping into the scalar helping destructor (a helper function set up by Visual Studio for the destructor). You can also see this from the call stack.
Stepping out with Shift+F11 should bring you directly into the destructor's code.
Regarding why this is happening it could be that Visual Studio is breaking into the helper function (glitch?) or that you're entering that function by stepping into it before the actual destructor code gets executed.
If that bothers you you might also take a look at breakpoint macros and see if that helps (try stepping out of the scalar deleting destructor if putting a breakpoint on the first line of the destructor doesn't help)
You can show the stack window (Debug -> Windows -> Call Stack or Ctrl+Alt+C in Visual Studio 2013) and then double-click on a stack frame that is in your code to see where in your code the break is happening.
Related
In Visual C++ 2015, the memory debugger window shows
"Unavailable when debuggee is running."
when the process is running.
Is it possible to show and reevaluate the memory at a certain address without pause the process, like a live view?
Yes, it is possible. Place a breakpoint, open breakpoint settings button (gear) and set action to print log message containing the value of variable of interest such as {var_name}. Example:
auto i{0u};
for(;;)
{
++i;
}
will print the value of i into VS output window every 10000 iterations.
This screenshot if from VS2017, but it should probably work for VS2015 as well.
I am using Visual Studio 2012 for my project in C++. I have a function where I put a break point.
MyFunction(int userid, double totalamount,char *ce_account_ref_num, int payment_type)
My debugger goes to this point and shows some undesirable inputs for userid. Is it possible to go back to the point where this function is called and verify inputs?
In the Call Stack window (usually on the bottom-right of Visual Studio), double-click the line with the name of the method where you want to see values of variables.
You can do many things but maybe the best choice is to comment all the lines in your MyFunction method and step over to the next line outside MyFunction to check the variables. You can also check the Call Stack and Call Hierarchy to see where your function is called from, in the case you have more than one call to the same method.
Unfortunately it is not possible to role back(undo executions) to the point where this function is called. However you can try put break point right after you give input and verify it. Call stack is also helpful to track how your program flow sequence get there.
I do this by pressing ctrl and - . This can be done recursively (press the combination again). This takes me back to the point where my cursor was last. By doing this I can go back to where the function is called and check the values etc. And by the way you can execute the same function again (in debug mode) by going to the point where the function is called by selecting "set next statement" from the right click menu, while you are debugging - a very powerful feature.
When I start the program, I get the dialog and everything. But it closes by itself after some 10 seconds. How do I disable that?
EDIT: This happens when I run "Debug -> Start Without Debugging". This is the only way I know how to run the program.
EDIT2: My dialog is inheriting from CDialogEx.
If your dialog is not modal, i.e. you are not firing it up using the DoModal() member function, it is possible that it is being created with the constructor, and deleted with the destructor as it goes out of scope. You see this type of behaviour with some implementations of splash screens. To figure out what is happening, put a breakpoint on your dialogs destructor, and look at the call stack that is leading to it. It is also worth turning on all exceptions in the debugger, as you could be getting hit with an uncaught exception that is terminating your app.
As others have already said, this is not normal behaviour for an MFC app.
Usually dialogs do not behave that way.
But in default, they close on OnOk (CDialog::OnOk) which is "Enter Key Pressed"
and OnCancel (CDialog::OnCancel()) which is "Esc Key Pressed"
Try overloading those two in your Dialog, to see if those get called and to handle
the behaviour there as you like it.
Perhaps the Close event should also be handled or watched.
here are lots of examples of what can be done with a Dialog (especially OnOk, OnCancel and Close) CDialog Examples
I was facing the same issue with Visual Studio 2013:
I was creating the most basic MFC application with the Visual Studio wizard (either dialog-based, Single/Multiple document based), and just recompiling the generated code. No modification to the code at all.
I just found out that the "restart" does not occur when I turn off my Anti-virus. :-)
This is not a bug in Visual Studio, it is an environment problem.
My anti-virus is Avast.
The solution for Avast is to turn-off the Deepscreen feature.
There, go to Settings / Active Protection / Deepscreen - and disable that.
More details could be found about this approach to the solution on Avast's forums, from this discussion:
https://forum.avast.com/index.php?topic=139935.0
Confirmed, this happens with Visual Studio 2010, and doesn't happen with Visual Studio 2008. That means all the negative votes were completely unnecessary. It's a default of Visual Studio 2010, I didn't change anything. Nor did I make any bug, because I explicitly said that I created a new application without changing anything.
Thanks for all the negative votes.
Just for the record, I tried this using Visual Studio 2010. I picked Dialog-based application and left all the other options at their default settings. Compiled both Debug and Release configurations, for x86 and x64. When launched using Start without Debugging none of the four executables terminated by themselves.
If this is happening for you I would assume you have some application running (in the background) that interferes with the expected behavior. Try setting up a virtual machine, install a clean Visual Studio and perform the same procedure again.
I am facing a odd behavior of Breakpoints in Visual Studio 2010 Express. Below is the code with breakpoints.
I am able to break at the first breakpoint (Line 159), but stepping after line 160, the cursor vanishes, i.e after this image of code pressing F10/F11 the application is displayed.
The problem is,
Why isn't line 162 executing (Without this statement, asserts fail elsewhere) or breaking at it?
Note : The line 166 Refresh(); is being executed, because the application displayed is updated.
EDIT : On suggestions in comments, I stepped through disassembly, and I found this line (from wxWidgets library) is causing the debug to fail 00D5AF7C call wxCharBuffer::~wxCharBuffer (0D207AAh)
Have you tried stepping through disassembly? With combined assembly-source view you can tell what exactly is going on.
To do that once you hit a breakpoint go to Debug->Windows->Disassembly. Or just click RMB and then "Go to disassembly".
Sometimes when I use the debugger to step through my code, it goes into some assembly code (I guess I've stepped into some system library code).
The question is, how can I skip over it and jump to the nearest c++ code of my project?
Use the "Step-out" button or Shift+F11, this will step back up the call stack.
Alternatively display the call stack (Alt+7), then double click on the function level you want to return to; this will indicate in the source window where the call was made. Then in the source window right-click the statement following the call, and select "Run to cursor". Of course if you already know where the call came from, you could just use "Run to cursor" in any case.
You can close that assembly window by clicking X on right side in the code window. Not the one at top most right(which closes the solution)
Jump Out of the current function? (Shift-F11 in the C++ settings?)