I'm debugging a code in VS that I wrote in C.
For some reason, at some point it jumps to an assembly window with the following line:
int 3
And a pop up message box appears with the following message:
User Breakpoint Called From Code At 0X7c90120120e
I looked at the stack, and the command that caused that was MALLOC !
In output window:
Heap missing last entry in committed range near 22549c0
The weird thing is, when I press OK at the message then F5 to continue debugging it continues and everything works 100%. But when I try to execute the code I get a message that my project encountered some problem.
I tried cleaning my project, rebuilding, removing all breakpoints .. nothing worked.
First of all thank you all for commenting/ answering.
I solved the problem. I found out that I was trying to Free the same memory TWICE.
The reason that I didn't notice it before is that the "Free" (delete function) wasn't in the same function nor the same file as where the debugger stopped/ the breakpoint occured(on malloc).
So if anyone is having the same problem, just make sure you are not Free-ing the same memory more than once.
Possible duplicate of this stack overflow thread.And here's an explanation of this problem in this link.Hope that helps you out.
Related
I while ago when I had a crash in Visual Studio it would show me the lines where the code crashed as well as all the lines before that that called the function containing the line on which the code crashed.
Since a few months and a few updates in Visual Studio, it started showing only the line on which the crash happens. For example, my code is crashing and the debugger has opened the header file and is showing the line in there where the code crashed but it is not showing the lines that call the function in that header. Previously it would show the lines that call the function, starting from the main function of the program in which the header is used. And I could easily workout which part of the main program is making a bad call to the function in the header.
Is there a way to have it show me all the lines like before? I've searched everywhere online and cannot find this.
I was able to find how to display the call stack window: while debugging, in the Debug menu, select Windows > Call Stack.
This shows all the function calls down to the line where the crash happens. Solved the cause of the particular crash straight away by the way.
I have a problem regarding the result of my program. I have a bi winforms application that makes a lot of things. One of them is visualizing a bunch of data I have stored in several .txt files in a given directory. It takes one, read it, close it and then visualize it before reading the next one.
My problem is that if I just execute the program, tell it the directory of the files and ask for visualizing, after reading 2 or 3 files it crashes because a memory access violation. But if I reproduce the exact steps while executing from the debugger of visual studio there is not any error nor warning nor nothing, it just works fine.
I know that the debugger is exactly that, a debugger, and thing execute differently in a debugger, but I dont have any idea why this happens.
Any idea why my program crashes? Or what should I do for avoiding a crash?
I know my question may be too ambiguous, but I don't have other method to show you my problem, unless you want me to post a 20.000 lines code :) .
Thanks in advance.
Attach the debugger after the crash (JIT debugging).
http://msdn.microsoft.com/en-us/library/5hs4b7a6(v=vs.80).aspx
I am getting this error with my c++ code:
http://imageshack.us/photo/my-images/193/vcerror.png/
The only problem is it doesn't point me to where the problem is... I understand the string subscript is out of range but I have no idea where it could be.
I was wondering if there is anyway I am able to find where it is? I have a rough idea so I have put a breakpoint in there but how VC++ does breakpoints is horrible. I step-through but it only shows me the code from the C++ files themselves, not my own code.
So, I step over and the error shows straight away.
How can I track down this problem?
Basically, you need to look at the callstack and have all your symbols setup.
I'm going to take a wild guess and suggest that you may not know how to use the "call stack" window.
In a debug session of your program and no breakpoints set, allow your program to run until it hits the assert dialog. Press "retry" to allow control to be passed to the debugger. Another dialog may pop up to prompt you to "break" or "continue". Select break. You should be broken into the debugger at this point.
Then make sure you can see the call stack and have at least one watch window up.
Debug->Windows->Call Stack.
Debug->Windows->Watch->Watch 1
You can double-click on any item in the call stack window to jump to the exact line of code where execution is expected to return to. (Sometimes the little arrow on the editor window is pointing to the next line of code to run after the previous call returns). Double click on the function line in the call-stack window that is directly below the top call stack line. That's likely std::basic_string::operator. What value is getting passed into this function? If hovering over the variable name doesn't work, add it to the "Watch" window. Also, add a watch for "this" so you can analyze the actual size and capacity of the string.
Double click on the function call in the call-stack below where you are currently at. This should take you to the actual buggy line of code in your program. Add another watch for the string variable and should be able to figure out what went wrong.
The rest is up to you.
I'm assuming this is a standalone EXE project with everything build by the IDE. If it is not, then make sure the PDB files from each binary produced is in the same directory as the corresponding binary. Again, if this is a simple EXE project in Visual Studio, this is automatic. Just to be sure, make sure you "Clean" your build first, then do a complete rebuild. That sometimes fixes debugging kinks.
I'm having trouble with my program crashing. I get that "Program.exe has stopped working" windows pop-up which mentions my exception code is c0000005. When I return to the output from the application in Qt, it shows:
C:\Users\Me\Desktop\project\project-build-desktop\debug\project.exe exited with code -1073741819
I've found the line that's causing the error (I think!), though I don't know why it might. If I comment out this line, the program won't crash.
The line is:
db=newDb;
This is located in the constructor of my class wndChildWhatever which is a QMainWindow. newDb is defined in the constructor arguments as DatabaseManager *newDb and db is a private member of wndChild defined as DatabaseManager *db. This database address is passed around all over my program, and this wndChildWhatever is the only one I'm having trouble with.
The exception/crash doesn't occur when the window is opened/constructed, however. It happens when the window is closed. What's weirder is that it doesn't happen every time. Sometimes you can open the window and close it with out problem, then open it again and on the second closing, it crashes. Other times it happens the first time you try to close it.
I'm really not sure what's going on here and hope someone can assist!
The faulting line:
db=newDb;
And you say:
and db is a private member of wndChild
It sounds like your this pointer might be invalid. That is, if this happens in a method foo you are doing something like wndChild->foo() and wndChild is an invalid pointer. Therefore when it access the offset of db relative to wndChild you hit an accesses violation. (NT error code 0xc0000005, Windows-speak for a bad pointer dereference.)
Most likely it's not the db=newDb line itself that's causing the crash, but rather some other code that gets executed later on, that doesn't get executed if you don't set the db value. Have a look at the other code inside your wndChildWhatever class, and see what it is doing with the (db) value. Perhaps it is doing something naughty, like deleting it while other code is still using it?
With the line db=newDb you have two pointers to the same object. What do you do in the destructors? If you have "delete db" and "delete newDb" you delete the same object twice which may lead to a crash or not.
Try to delete the build directory and rebuild it. It worked for me, but i need to do it everytime I add a new function or member to any class. Idk why.
I am debugging an Iphone program with the simulator in xCode and I have one last issue to resolve but I need help resolving it for the following reason: when it happens the program goes into debugging mode but no errors appear (no BAD ACCESS appears) and it does not show where the code fails. Putting some variables as global helps me to see their values to start pin pointing where the bug is but before I go into this fully I would like to know what techniques/tools you guys use to debug these situations.
If it helps Im debugging the following: I merged some code into the SpeakHere demo. The code was added in the C++ modules of the program (AQRecorder.h and .mm). I seem to have pinpointed the problem code in a function I wrote.
My favourite is always to add debugging code and log it to a file. This allows me so report any and all information I need to resolve the issue if the debugger is not working properly.
I normally control the debugging code by use of a flag which I can manipulate at run time or by the command line.
If the error is (and it probably is) a memory management issue, printing log entries is really not going to help.
I would reccomend learning how to use Instruments, and use its tools to track down the memory leak when it occurs rather than waiting until the application crashes later on.