Run-away debugger

[lohill]

What is causing the IDE to run past break points while in the debug mode. It is so frustrating to step through the code looking for values of variables and then have the debugger just zip through all the rest of the break points making it necessary to start over. This has been my experience on a Mac ever since starting with Revolution a few years ago. Sometimes, if I reset all the breakpoints or set some new ones, I can make progress but I never know when it will start disregarding them. Is there some good work-around?

Larry

[dunbarx]

Hi.

I have never seen this. When you say "in debug mode" do you mean that when you are already stepping through, and press the "continue" button, that execution skips downstream breakpoints? Or that breakpoints are not caught from the IDE itself? Are you using explicit breakpoint commands or the sidebar shortcuts?

Craig Newman

[lohill]

Craig,

I'm not sure what you mean by 'explicit breakpoint commands or sidebar shortcuts' bit I click to the left of the line number and place a red dot there. When I click the button to exexute command or press the green arrow, the commands are executed until the 'dot' is reached. At that point I am usually trying to see the value of the variables by either hovering over their position in the script or by scrolling through the list of variable values at the bottom of the window. I generally do this while there are multiple breakpoints yet to be stopped at below. At least 10 % of the time while hovering or scrolling the list, execution automatically starts even though I have not clicked on the step icon or the arrow. Once that gets triggered, execution continues through all the rest of the break points. If I execute the code again is sometimes may stop at the first but sometimes it will go through the whole set again automatically. That is when I turn off the breakpoints (click to grey) and then turn them on again.

As a side question, is there a way to eliminate all those environmental variables from the list at the bottom? I almost never want to see them and since they are at the top, I am always forced to scroll which I think triggers the run away.

Larry

[jacque]

I've seen it happen. Ususally it's because a library script is accessed for that line of code (and the IDE has dozens of libraries running at all times.) When the library script is executing, the debugger can "forget" where it was and stop recognizing breakpoints. I can usually solve the problem by moving the dot to the next line down so that the library call is finished before the breakpoint occurs.

[jacque]

Hi.

I have never seen this. When you say "in debug mode" do you mean that when you are already stepping through, and press the "continue" button, that execution skips downstream breakpoints? Or that breakpoints are not caught from the IDE itself? Are you using explicit breakpoint commands or the sidebar shortcuts?

Craig Newman

The debugger ignores all downstream breakpoints, regardless of whether they are set with a red dot or an explicit "breakpoint" command. You can usually break at the first breakpoint, then when you click the Continue arrow it completes the handler without recognizing any subsequent breakpoints. I see this almost daily in my current project.

[dunbarx]

Jacque.

The debugger ignores all downstream breakpoints, regardless of whether they are set with a red dot or an explicit "breakpoint" command. You can usually break at the first breakpoint, then when you click the Continue arrow it completes the handler without recognizing any subsequent breakpoints. I see this almost daily in my current project.

What do you mean? Are you still referring to the Library instability?

Because from 1987 to yesterday, all downstream breakpoints are caught, thank heaven, as advertised, regardless how you pass the first one.

Craig

[jacque]

I misspoke slightly, subsequent breakpoints may trigger, but those that occur on lines that go into a rev library (or a locked library) may not. The behavior seems to vary because some people have reported that all subsequent breakpoints fail, but for me if I place the break after the line that fails it will usually work. Since you're on the mailing list, you may remember Dr Hawkins complaining that no breakpoints would work for him after one of them failed.

If you have set gRevDevelopment to true, I think (but haven't tested) that breakpoints should work all the time because you are then allowed to step into the library scripts. Otherwise the IDE skips over those to protect you from the IDE code.

I'd give you a script example where it fails for me but I'm so used to the behavior that I just reset the break and move on, so I can't pinpoint one off the top of my head. If I remember I'll make a note next time it happens.

[dunbarx]

Jacque.

I now see what you are saying. But I have never seen it.

But I am intrigued and a little disturbed to know that this lurks somewhere. It seems that the "step into" and "step over" gadgets ought to manage this perfectly. In other words, why is a library script different than a function or custom handler call, where you can step "into" or "over" that call?

I appreciate having the option to "step into" a library script. I consider it a mean spirited bug that the debugger might "step out" of a script entirely.

Craig

[jacque]

If you set the break before the problem line, the step-over works. It's only if you try to break on that particular line that there can be a problem.

[Simon]

OK my turn.
I have seen this problem before but now it's really being a pain.

I swear liveCode is behaving like HAL and doesn't want me to see the error it's made!
"What are you doing Dave?"

Libraries yes, working with SQL queries.

Simon

[mwieder]

The built-in debugger has... er... bugs. One of those is a side-effect of the limitation of stepping through the system libraries. Once you start trying to debug your way through a system stack, the debugger automatically goes into "run" mode. PowerDebug doesn't have this problem, and you can step past calls into libraries.

[lohill]

I sure would like to call this to the attention of the LiveCode people. I think thus problem is being experienced by everyone that uses LiveCode in a non trivial way. This is something I have experienced regularly on both a PC and Mac and as recently asa Community version 7.0 (dp-5). I personally do not think that the LiveCode team should be allowed to do any further work until this gets fixed.

Larry

[FourthWorld]

I agree, Larry, but historically the challenge has been coming up with a reproducible recipe. If you have one, please submit it in a bug report:
http://quality.runrev.com/