Anjuta IDE debugging program is easy to ignore

Anjuta IDE debugging program is easy to ignore

First, let's talk about my system environment: The system is Ubuntu
8.10. build-essential is installed and upgraded to the latest gcc and libc versions. Other libraries and development environments related to gtk are installed. You can use glade3 for gnome graphic interface development.

Anjuta
IDE, version 2.4.1, should be a relatively new stable version. The general feeling is good, but I always think that the built-in debugger is sometimes strange, for example, sometimes it is not stopped in the place where you break the breakpoint, or
When you press F5 to perform one-step operation, it is found that the program does not run according to the proper logic. A typical problem is that if you assign values to or judge a local variable under a breakpoint, the debugger will not be able to recognize this variable, and there is no
Method, and so on. The following is an example:

Figure
It can be seen that the breakpoint is clearly located in 49 lines, but after the debugging is started with shift + F12, the program is directly interrupted in 50 lines. In addition, when you press F5 for a single step, it does not enter the for loop, but directly jumps out.
Loop to execute the next statement. In addition, the "idx" variable is specified in monitoring, but the values and types are both "?". Apparently not recognized. However, other code, such as printf or letter
Call number to track debugging.

Later I referred to manual of anjuta and found a note:

In
Order to better user the debugger, It is stronugly recommended
Debug program with debugging information (-g for GCC) and no
Optimization (-O0 for GCC). This can be done by selecting the debug
Configuration before building the program for the first time.

By
Every time you run a program, you can directly use the Wizard to generate a project. Then, you can directly generate related files using automatic tools such as automake and autoconfig without worrying about specific compilation parameters.
Configuration options. As mentioned in the above text, debugging information (-g parameter) needs to be enabled, and code optimization (-O0 parameter) needs to be disabled. Therefore, this issue is likely to occur. After some tests, the simplest way is
Method:

First, you need to clean up the configuration. In the "generate" menu, there is a "clean up configuration" function at the end. Click it.

 

However
Open the "configuration project" dialog box under the "generate" menu. A "configuration" drop-down menu is displayed. The default menu is "default", and other options include "debugging. You do not need to select another one and build a directory.
Do not change. Check "regenerate project" and enter the code 'cflags =-G "in" configuration options ".
-O0''cxxflags =-g-o0'' jflags =-g-o0'' fflags =-g-o0' (including single quotes). Run the command.

If the execution process is successful, you can use Shift + F11 to generate the project. If everything goes well, now you can debug it properly. For example, in my example, after the same breakpoint is processed as above, the debugging result is as follows:

Obviously, the program is interrupted at the breakpoint position correctly. The idx variable can also be recognized.

To sum up, this problem is actually very simple, because the debugging function cannot fully operate because the program is not compiled based on the debugging configuration. Of course, when debugging is complete and you want to restore the normal configuration, repeat the above steps, leave it blank in the configuration options, and then reconfigure and generate the project.