1. Master Slave debugging: I have an application that runs in Master Slave mode. The job of Master is to provide a network interface to the outside world. It receives requests over http and hands it over to the slave process after serializing it. The slave process reads the request through Pipes, deserializes it, processes it and passes on the serialized response back to the Master which in turn sends the response to the web user. There are xtensions (also known as plugins) attached to this application. I wanted to debug an xtension. I applied breakpoints in it and set the executable path to the path of the application. The breakpoint was not getting hit. The reason was that I was debugging the xtension in context of Master whereas the callback to be received was issued by the Slave. So rather than launching the application through the Xtension, I first double clicked the application exe and then used "Attach to Process" to attach the Xtension to the slave and not master.
2. I had two Xtensions (plugins) built in Release mode with debugging information on. I was debugging an xtension which issued a callback. This callback was received by the second xtension. When I tried to do "Step Into" or F11 at the place where callback was issued, it didn't work. I expected the control to move into the source code of the second xtension. However, I opened a source file of the second xtension where I expected the "Step Into" will take the control to. There I put a breakpoint. Now "Step Into" worked and it took the control to the breakpoint of that source file. The reason why the breakpoint was not being hit earlier was because when first xtension issued the callback, a method from the exe was called whose source code I didn't have. This method further called all the xtensions registered for the callback. Since I didn't have the source code, the "Step Into" was not working.
3. If you want to debug an application or a library built in release mode which has debugging information on, and you apply a breakpoint in the code against which VS shows a hollow circle signifying that symbols are not loaded against the code, then check that you don’t have checked on the option of “Strip Private Symbols”. In case, it is on, turn it off.
2. I had two Xtensions (plugins) built in Release mode with debugging information on. I was debugging an xtension which issued a callback. This callback was received by the second xtension. When I tried to do "Step Into" or F11 at the place where callback was issued, it didn't work. I expected the control to move into the source code of the second xtension. However, I opened a source file of the second xtension where I expected the "Step Into" will take the control to. There I put a breakpoint. Now "Step Into" worked and it took the control to the breakpoint of that source file. The reason why the breakpoint was not being hit earlier was because when first xtension issued the callback, a method from the exe was called whose source code I didn't have. This method further called all the xtensions registered for the callback. Since I didn't have the source code, the "Step Into" was not working.
3. If you want to debug an application or a library built in release mode which has debugging information on, and you apply a breakpoint in the code against which VS shows a hollow circle signifying that symbols are not loaded against the code, then check that you don’t have checked on the option of “Strip Private Symbols”. In case, it is on, turn it off.
No comments:
Post a Comment