Why cannot I debug s60 Simulator version 5?

Yesterday, my colleague suddenly came to me and said that it was a compiled program. There was a problem with the s60 Fifth Edition simulator. It was only possible to open it for the first time and exit and enter again, but it failed. There are two types of phenomena. If you click to enter the menu with the mouse, there is no prompt. If you use the keyboard up or down key to locate the icon and press enter, the "menu: system Error (-1 )".

 

This colleague su sun is also well known for his technical skills. This time, he also did a lot of tests in advance and told me a seemingly inexplicable rule: There are two CPP files in the MMP file, so it will be normal to comment out the files, A problem occurs when you open it. The magic thing is that the classes in the two CPP are not used anywhere. The first response is that a global object exists. After careful code check, this situation is ruled out. According to the value of-1, it is suspected that some useful files are accidentally deleted after the first execution of the program. After a large number of pre-and post-comparison operations, this situation is also ruled out.

 

At this point, although I think it is impossible, I began to doubt the code problem. First, I suspect that all the statements that use resources (or the-1 Statement, always think that something is missing) have not been solved. Then I comment out all the code outside the pre-compiled command, the problem persists. Then, comment out all header files, and the problem disappears. This phenomenon is preliminarily inferred to be related to header file inclusion. In turn, I tried to release the commented-out header files one by one. The results only contained the first header file, and the problem appeared again. It was very exciting and seemed like a turning point. This header file is the project code. In addition to the system header file, it is our class declaration. I have no doubt about the system header file. I will comment out our code first, and the problem persists. We had to start to suspect that the system header file was shielded and opened one by one for testing. We found that four of them would cause problems, and one of them was named aknsettingpage. h. After continuing the test, we found that if both CPP files contain this file and are added to the project for compilation. A problem occurs, and a CPP is removed from the project, and the problem disappears. We have two wide-eyed eyes, and we cannot believe them. So yesterday.

 

I have been busy with other things this morning and will continue this afternoon. My colleague also told me a new trend. After he adjusted the free memory option in the simulator from the default 48 MB to 128 MB, the situation improved slightly. The original situation is that once the second attempt to enter the program fails, the simulator is closed and then re-opened, the program still cannot enter; after the idle memory is adjusted, there is progress. After the simulator is re-opened, the program runs for the first time. I suddenly suspected that the problem could be caused by the memory allocation and occupation of the simulator. So I took a look at the executable file size in winscw, which I would barely pay attention to. I am sorry, 67 MB! Almost every CPP corresponds. O the file size is close to 1 MB, and only one file contains aknsettingpage. h header file statement CPP, corresponding. O is actually more than six hundred kb, and I am more confident that my doubts are true: due to the increase in engineering, the number of CPP files increases, A large number of debugging symbols are linked to the executable file, which causes rapid expansion of the volume and the simulator cannot be loaded normally. In addition, I can give a reasonable explanation of the phenomenon. After hearing this, my colleagues asked me to confirm it. The subsequent experiments (constantly adjusting the value of free memory and observing program startup) made my colleagues more confident about the memory. The fact that my colleagues and I share the same view is that we reproduce the two scenarios where the previous problem occurred and did not appear, and compared their executable files, the size of the problematic file is 656 xxkb, but not XKB. Out of the high sensitivity of computer professionals to the number 65536, they finally unified their understanding.

 

As a result, my colleague posted two notes to his group:

1. Do not include unnecessary system header files in CPP. This will introduce a large number of additional symbols.

2. If it is reasonable and feasible, it is recommended to merge multiple CPP into one so as to effectively eliminate redundant symbols.

 

In fact, after testing, he used the copy *. cpp XXX. cpp command to merge the two groups of CPP into two CPP, which reduced the size of the executable file by nearly 20 mb.

 

The end is a by-product in the test process. In the MMP file, you can use the option statement to specify the command line switch to the compiler. This option statement is not mentioned in the previous official documentation, but the latest documentation is made public, you can refer to: http://library.forum.nokia.com/index.jsp? Topic =/s60_5th_edition_cpp_developers_library/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/SDK/doc_source/toolsandutilities94/build-ref/matrix filestatements.html. I used the option CW-sym off statement to disable the reserved udeb compiled by winscw, reducing the executable file of the 67 MB version to 9 MB, the other 81 MB version is reduced to 12 Mb. However, the negative effect is that the breakpoint in IDE can no longer work.