Is the Netlinx debugger broken?

ErikJackman

I'm trying to debug a routine that involves string parsing. I'm trying to debug the parser but every time I try to look at the variables holding the two pieces of the string the debuggers watch table butchers the values. Instead of showing me the results of the mid_string commands I get the same number in both variables that has absolutely nothing to do with any of the code the system just executed.

Coming from the computer programming side of things and being used to Visual Studios debugger which I love. I can't tell you how frustrating it is to deal with NetLinx's debugger in contrast. It makes me want to scream and pull my hair out and I'm only doing a simple mid_string. How the heck am I supposed to be able to debug the code if the watch table doesn't work half the time? I need to be able to see the values of the variables all the time not some of the time. Also the debugger loses the yellow arrow and the break point icons sometimes so I end up not being able to see where in the code I am stepping through and have no way to tell if it's hung up on a break point if I click run and it hits a break point I didn't think was there anymore.

Sorry I just have to vent so I'm rambling right now but please AMX for the love of GOD fix your debugger.

</rant>

Spire_Jeff

If you are trying to track a STACK_VAR, you will run into problems with the variable disappearing because they cease to exist after the code runs (and the debugger does not remember them). Also, I believe that stack_var char arrays are not initialized to null values, which might explain the weird characters if you have it set to show the entire array contents.

Don't take this explanation as an endorsement of the debugger, just somethings I have figured out. Also, the debugger/compiler seem to interpret line numbers on their own terms, so I find a need to blanket the area I am interested in with stop points and then step through when it trips. The only time I lose the arrow is when code execution goes into a module that I don't have the code for.

Jeff

a_riot42

Yes its broken. I only use it to track array or variable contents. If you create a breakpoint, you often can't delete it so the code will stop at that line of code every time from then on. Save your hair, don't use it.
Paul

PhreaK

The debugger definately is lacking in areas. I personally haven't had that much in the way of major issues with using break points though.

In case any of the AMX boffins happen to be reading http://www.cs.cmu.edu/~NatProg/whyline.html. Pretty please.

DHawthorne

You aren't, by any chance, setting the debug window for the variable you are watching to total length, are you? Strings in NetLinx are just like strings in C: a pointer to a memory location with a length so it knows where the string stops. If you are set to total length, you are going to be looking past the end of that string into the rest of the memory space; that doesn't mean the program will actually treat it as part of your string.

Also, if you are debugging a module that has more than one instance ... well, just don't . The watch variables will show the same for both instances no matter what.

Aside from those issues, and the already mentioned stack variable thing, I have not had any trouble watching strings in debug. I often, however, resort to commenting multiple modules out, or temporarily changing stack vars to local.

Jeff

I know this is somewhat unrelated to your particular issue but I mention it anyway so you'll know what to look for.

1) Multiple instances of the same module make the debugger cry. When you try to watch a variable in one of the modules, it'll give you an option of which one to watch, but a) rarely are the locations of each variable correct and b) it doesn't always work anyway

2) Modules make stepping through code impossible. The more modules you add, the further off the debugger is from the actual line it's stepping through. Near as I can tell, any line of code that calls a module doesn't seem to exist to the debugger, so if you devote 6 lines to calling 6 modules, any time you step through code, you'll be 6 lines off. It's nigh impossible to see what's going on.

Final Answer: Netlinx Debugger = FAIL

J

vining

Jeff wrote:

it'll give you an option of which one to watch, but a) rarely are the locations of each variable correct and b) it doesn't always work anyway.

Yeah that's a real pain. You would think there would be a logical order but I'm never sure what that is. I find it easier just to pass a module ID into it so I can quickly verify which it is in the debug window.

I'll send a simple nThisMod in as a paremeter and assign it a value in the main code or include file which instantiates it. Otherwise it's often impossible to tell which module variable you're looking at.

The Debug variable watch windows always seems to work fine but break points and such are worth even trying.

ericmedley

vining wrote: »

Jeff wrote:

Yeah that's a real pain. You would think there would be a logical order but I'm never sure what that is. I find it easier just to pass a module ID into it so I can quickly verify which it is in the debug window.



I'll send a simple nThisMod in as a paremeter and assign it a value in the main code or include file which instantiates it. Otherwise it's often impossible to tell which module variable you're looking at.

The Debug variable watch windows always seems to work fine but break points and such are worth even trying.

I have found that the debugger/var watch is a little crash prone when you try to watch to many buffers at once. I've never gotten breakpoinrs to work for me. I just throw in flags or send_strings in the code to catch or trap stuff.