NNDK 2.6 Debugger

[keckrl]

The NNDK 2.6 Eclipse Debugging does not seem to work. At first I assumed it was a MOD54415 issue, but I tried it with a MOD5270 and it also does not work. Symptoms include: Pause doesn't work, breakpoints cannot be set, and debugger does not terminate correctly (actually I haven't found any debugger feature that does work). This is true on Win 7 x64 and an XP Mode virtual machine.
I went back and tried the MOD5270 with the NNDK 2.5.3 on an XP Mode virtual machine and it works fine, so the problem seems to be the NNDK 2.6.
This is going to be a significant issue for users of the MOD54415 since 2.5.3 does not support it.

[tod]

I wish I had seen this post before I started experimenting anew with the debugger. I just made a post about debugging problems. I thought it was because my code was in libraries. But it looks like the problem might be more widespread. It also looks like I had a "little" more luck than you. I can set some initial breakpoints (as long as they aren't too close to the initialization statement for the debugger). When I break in I can examine variables and such. Unfortunately I can't set any breakpoints afterwards and if I clear a breakpoint I can't set the same breakpoint again. Good to know it used to work better in previous versions.

[sblair]

What's the story with this? I was just about to purchase a Support Renewal for the Mod5270 so I could upgrade to 2.6.0 but I can't afford to reduce debugging capability...

Has it been resolved?


Thanks.
Scott

[tod]

I haven't had time to submit a reproducible example to NB. I still have problems. Since you asked, I decided to try again today and I'm running into the dreaded "Error creating session: localhost:2159: No connection" message. I would suggest starting a new topic maybe asking if the NNDK 2.6 Debugger is working for anyone. I'm not sure how many people are using 2.6. I know I'm a pretty bad test case because I use every tool in the C++ toolbox including the boost library, and 99% of my code lives in libraries.

[sblair]

"Error creating session: localhost:2159: No connection"

When I have encountered that before it is just because the IP address in the debugger config settings got lost. Once I re-enter the IP address in all the debugger config settings pane it fixes that.

Or is this a different problem than that?

[tod]

Duh, I checked and rechecked the IP settings on the first tab but then it finally dawned on me that the message says right in it "localhost", that is no good. So I slowed down and sure enough on the Debugger-Connection tab it had wiped out my ip and put in localhost. I even wrote up a blog entry on OCTOBER 3 of THIS YEAR! Right at the bottom I put a screen shot and this text: Finally, use the Connection tab and make sure the IP Address is set to the address of your NetBurner. This often defaults to localhost which is not going to do you any good. I guess I figured since I'd already successfully debugged this app it would be OK. I figured wrong. Maybe I should read my own blog. Time to run some more tests. Thanks for the heads up.

NB_SetDebugger_TCP.png (14.61 KiB) Viewed 7964 times

[sblair]

No worries. I just got bit by that myself recently and took someone here to point it out to me!

[tod]

So I just ran the debugger. Some breakpoints were set before I started and those were hit. Then while I was on a breakpoint I could clear and set some breakpoints in the same task/method. This all seemed to work correctly. While stopped in one task I went to the source for another task/method (my main event loop) and set a breakpoint. I got the breakpoint symbol (not a warning icon) I hit run but the breakpoint was never hit (easily proved later that it should have been). I then tried to set other breakpoints on that task's method and every line in the method I tried gave me a breakpoint at first and then a few seconds later it turned into a warning icon.

I quit the debugger, cleared and reset the breakpoints that didn't work. Since I wasn't running the debugger I got proper debug bullets. When I debugged again they were hit. I could again set breakpoints in the task/method I was currently stopped on. I could repeatedly hit a breakpoint in my main loop. When I cleared that breakpoint (and had no other breakpoints in that loop) I could never get back in. Trying to reset the breakpoint I had just been hitting repeatedly, resulted in a warning icon being shown and no breakpoint was set.

So my opinion is a little modified you don't need to set up all your breakpoints in advance, you just need to have one in the method you are interested in debugging in advance. It's a little more flexible than that, if you can stop anywhere in the task and step into the method of interest that will also work. Stepping into/over/return all seem to behave. Looking at variable values appeared OK. This is a little limiting but I could probably write extra code that gets hit only infrequently and set breakpoints on that in advance so that I can break in.

Using the option to bypass application load during debug builds is problematic for me and I'm now avoiding it.

Terminating and disconnecting always fails but this is not a big deal, the next time I go to debug I just get a warning and I tell it to continue.

Setting a breakpoint too close to the init code for the debugger doesn't work. Also not a big deal since you can add an OSTimeDly right after the gdb init.

Tod

[sblair]

Ok, so it sounds a bit less reliable than previous versions but doesn't quite sound like it is unusable from what you said. At this point would you advise upgrading to 2.6 or avoiding it if you had the choice?

There are some improvements in the library code I'd certainly like to pick up...

Thanks.
Scott

[tod]

I would caution you to get more data points. I'm just one developer, it's still possible there something in the way I'm building that is causing a problem. Unfortunately, I don't have much experience with the debugger on previous versions. I do find this version less than ideal, and there is one other thread where at least one other developer has similar problems.