I am using linux ubuntu , and I am using QTCreator 5.2 32 bit. I compile a program in debug mode, for debugging I use break point. when 1 compile it , it shows an assembly code and if I close assembly file and use F5 for run to next break point , it again shows assembly code,
how can I disable showing assembly mode?
Thanks
You cannot stop from showing assembly code while debugging, way out is just make sure you place break points in your code, so when you press resume button (F5 key in your case) it will come back to your code.
I have seen same behavior in Visual Studio (Windows) and XCode (Mac).
Related
I have an Android application with native c++ librairies.
I can debug c++ code with lldb, I can break, I can see the stack, the variables and their values.
The command 'source info' displays the correct break line code.
I use the command 'settings set target.source-map' to map the source code files, the command seems to work fine, no error, but Android studio don't open the corresponding source files in the editor... nothing happens when I double click in the debugger stack.
Sometime ago, it works correctly, I don't know if something changed in my compilation process or in Android studio, but it doesn't work anymore.
Any ideas ?
I know this is considered an out-dated question, but I'm just curious about it.
Build a simple C++ program setmode.exe(From the book Inside DirectX, MS Press 1998) with Visual C++ 6 SP6(VS98) with /Od /Zi, then load this setmode.exe into Visual Studio 2008 debugger(on the same Windows XP machine that runs VC6 compiler), I find that
Stepping through source lines works well.
Call stack is displayed well.
View variable values does NOT work well. Only some variables is recognized, many are not.
Then what is the reason for missing variable in VS2008? Any workaround(assuming I do not have the complete source code of setmode.exe to rebuild it with VS2008)?
See my screen shot to know it vividly.
I am new to FreeRTOS and RTSM simulator. I loaded the code of FreeRTOS and am trying to use the RTSM simulator (simulates ARM Cortex A9). When I change to DS-5 debug perspective and press Debug from Debug Configurations, the simulator seems to be running. The problem I am facing is that I am not able to step through my source code (for debugging). I put a break point in the first statement in main, and the control doesn't seem to be reaching there. (I am able to step through the assembly language code produced after compilation, but that is not what I need).
Any idea how to do this?
I've got a problem with gdb debugger. My console app shows me incorrect action results (some trash instead of normal string which I've got from XML ater the parsing) if I run it under a debugger plus I get SIGINT ( I don't output eol character and don't hit ctrl+c). Running my app with no attached debugger (just double click on .exe or Run menu from IDE) shows me correct results. What is the problem?
Some Info:
Windows 7 Pro Sp1 x86
gdb 7.3.1 (MinGW) and gcc 4.6.2 (MinGW)
Eclipse 3.7.1
Here is a gdb trace.
At this screenshot you can see the settings
Probably you have some memory corruption in your application and and they become visible when you use the debugger. In order to solve the problem we need to take a look on your source code.
I am new to Visual Studio 2005 and am trying to get to grips with it. I am using it to compile and debug an application called AAM-library (which I didn't write) which uses OpenCV 1.0. I have compiled the software and now I'm getting a runtime error.
To figure out the reason for the error (I know the line number and file name that generates the error, since the runtime error tells me) I want to step through the code in the few lines before the error. The error is in an openCV file called opencv/cv/src/cvshapedescr.cpp. To debug I have figured out that I can step through from the start of the program using F11 or F10 but this is taking forever to reach the error. Is there a way to get straight to the error? I'm trying to put a breakpoint in the openCV file, but this is not part of the workspace that I am working on, and so it doesn't seem to be having an effect.
Place a breakpoint a few lines before the error or use run to cursor. There is no magical "10 lines before this breakpoint" feature. (Intellitrace can do this for managed code but that's a whole different ballgame)
Also note that concurrent debugging was made a LOT better in VC2008, you might want to consider using a more recent compiler, such as VC2008 or VC2010.