Buggy debugger -- solved?

[Timothy Miller]

Hi Mark,

I found a workaround. I can debug a bg script with no problem as long 
as I do it from card 1 of that bg. Otherwise, the debugger window 
opens, but it does not debug. Several subscribers have replicated the 
problem, and the workaround.  It's not a big deal if you know the 
workaround. If not, it can be very frustrating.

I have version 2.6.1. It's not fixed yet. I believe it has been BZ'd.

I'll take a look at bug 329.

Best regards,


Tim

>Tim,
>
>I would like to know whether you have solved the problem you had 
>with debugging background scripts. If not, feel free to send you 
>stack to me. You can also add your (very good) analysis to bug 329 
>of the Bugzilla database.
>
>In my view, the debugger should never just drop out of debug mode. 
>It should give some feedback to tell the user why it can't continue 
>debugging. If we can figure out what happened with your stack, maybe 
>RunRev can add some proper error handling in the deugger.
>
>Best,
>
>Mark
>
>P.S. I'm quoting the entire previous message to make it easier to 
>recall the discussion.
>
>
>Timothy Miller wrote:
>>It looks like this thread might die. I hope not. I hope a 
>>knowledgeable someone is going to reply. I'd sure appreciate it. 
>>I'm depending on you guys. I've searched the docs, learned nothing, 
>>and taken all advice offered so far. Where else can I turn?
>>
>>The gist is, the debugger works fine in stack scripts, but I am not 
>>able to debug any background script. I'm talking about bg scripts 
>>that work perfectly, every time.
>>
>>If I move any background script to the stack script, the debugger 
>>works perfectly. I can replicate the problem, every time. If I 
>>split a sequence of handlers between a background script and a 
>>stack script, I can debug those in the stack, but not those in the 
>>background.
>>
>>Is this a bug or a feature? Is it well known? Documented? If so, 
>>where? If it's a bug, has it been reported? Has it been fixed?
>>
>>
>>Cheers,
>>
>>
>>Tim
>>
>>>>On 7/11/05 8:34 PM, Timothy Miller wrote:
>>>>
>>>>>The details of my debugger frustration, previously described:
>>>>>
>>>>>>It works fine on, for example, a simple mouseUp script in a 
>>>>>>simple button. However, if the button sends a message to a 
>>>>>>handler in a stack script (for instance), which then sends 
>>>>>>another message to another handler, nested or not, the debugger 
>>>>>>won't follow along. "Script debug mode" is definitely turned 
>>>>>>on. Step Into, etc., are absent and/or dimmed out, typically. 
>>>>>>Sometimes, I can see the script window open, several windows 
>>>>>>back, but I can't get to it until the script is done executing. 
>>>>>>I've tried setting multiple breakpoints in each handler, tried 
>>>>>>setting breakpoints by script. The script rolls right past them.
>>>>
>>>>
>>>>I think Eric mentioned this after you wrote last time, but the 
>>>>debugger doesn't track "send to" messages. It tracks everything 
>>>>else, but if you "send" a handler to another object the debugger 
>>>>won't follow along.
>>>>
>>>
>>>
>>>Thanks to Eric, Jacque and Mark on this thread. And thanks to Dan, again.
>>>
>>>First, let me clarify what happens, and what doesn't. The script 
>>>window opens at the breakpoint, but it does not come to the front, 
>>>and the script does not pause at the breakpoint. After the script 
>>>is done executing, I can move the script window to the front, but 
>>>it does me no good.
>>>
>>>Oops! I just solved part of the puzzle, but mysteries remain. Feel 
>>>free to skip to the second row of asterisks if you want. The 
>>>details lie between the asterisks if anyone is interested.
>>>
>>>
>>>************************** the dull details, perhaps now irrelevant, follow:
>>>
>>>
>>>Here's a typical sequence of events.
>>>
>>>On mouseup
>>>     get this
>>>     put that into field "theotherthing"
>>>     etc.
>>>      goForIt -- this is a message sent to the background script. 
>>>The bg script does receive it, and the script executes fine, but I 
>>>can't debug it.
>>>end mouseup
>>>
>>>Now, in the background script
>>>
>>>On goForIt
>>>      handler1 -- this massages some data, without changing stacks 
>>>or backgrounds. It terminates, so the script moves onto the next 
>>>handler in goForIt
>>>      handler2 -- more of the same
>>>      handler3 -- this goes to another stack, picks up some data 
>>>and returns. It also terminates
>>>      handler4 -- this is a handler that doesn't terminate. The 
>>>next handler is nested, in other words. Depending on an operator, 
>>>it calls either handler5 or handler6
>>>end goForIt
>>>
>>>The command "send" does not appear anywhere in this sequence.
>>>
>>>In reaction to the good comments of the good people on this 
>>>thread, and also in reaction to my desire not to look like a 
>>>whiner or an idiot, I re-tested. Same results. As follows:
>>>
>>>If I put the breakpoint in the button, the button script does 
>>>open, and I can "step into" through the lines of the button. Once 
>>>the script gets to the goForIt message, the script executes 
>>>without pausing, even though the window of the bg script opens.
>>>
>>>If I put the breakpoint at the beginning of the goForIt handler in 
>>>the bg script, at the the handler1 message, at the beginning of 
>>>the handler1 handler, in the middle of the handler1 handler, or 
>>>all of the above, or do the same with any other handler in this 
>>>sequence, the same thing happens. The script window opens, but 
>>>it's not the front window, and the script runs to completion, 
>>>without pausing. When the script has executed, the script window 
>>>remains open.
>>>
>>>After reading the docs again, I realized that I can initiate 
>>>debugging when the error window opens. So, I deliberately placed 
>>>an error at various points in the goForIt handler, or in hanlder1, 
>>>handler2, etc. The debug button on the error window did respond, 
>>>and took me to the error. The script has paused, the script window 
>>>opens, but the debugger buttons at the bottom of the script window 
>>>(step into, etc.) are absent, and the corresponding items in the 
>>>debug window are dimmed out. The script stalls. All I can do is 
>>>remove the offending line, save, and run the script again.
>>>
>>>
>>>
>>>**************************  The more productive part starts below:
>>>
>>>
>>>
>>>Maybe there's something about background scrips. As I write this, 
>>>it strikes me that I've put most scripts of this nature in the 
>>>background script. I just tried a similar kind of 
>>>button-handler-handler-etc situation, where all the handlers are 
>>>in the stack script. These seem to debug just fine.
>>>
>>>Maybe this is why the debugger seems to have worked at some times, 
>>>not at others. I didn't notice the pattern before.
>>>
>>>Now I'm going back to the script described above. I'm moving 
>>>handler1 to the stack script. If I put the breakpoint at hanlder1 
>>>in the stack script, I can "step into" all the way thru handler1. 
>>>When it terminates, and control reverts to the bg script, I can't 
>>>debug any further.
>>>
>>>My hypothesis is -- there is something different about bg scripts 
>>>-- maybe several things. In a way I hope so. I'm gonna feel really 
>>>stupid if no one can reproduce this issue at this point.
>>>
>>>If background scripts are "different," what's different about 
>>>them? I looked through the documentation pretty carefully, but 
>>>didn't find any mention of this.
>>>
>>>If others on the list haven't have this problem, maybe most 
>>>experienced users avoid background scripts, avoid turning on 
>>>"behave like a background" or don't have HCaddressing turned on. 
>>>(In my case, "behave like a background" and HCaddressing areturned 
>>>on.) If that's true, few people on the list would have noticed 
>>>this issue. It's also possible it's an OS X-only problem.
>>>
>>>Should I have known that the debugger doesn't work properly in bg 
>>>scripts? Or maybe this is an un-reported bug in the debugger?
>>>
>>>Your ever faithful fumbling amateur,
>>>
>>>
>>>Tim
>
>--
>
>eHUG coordinator
>mailto:europe at ehug.info
>http://www.ehug.info
>http://home.wanadoo.nl/mark.sch
>http://www.economy-x-talk.com
>
>Please inform me about vacancies in the field of
>general economics at your institute. I am also looking
>for new freelance programming projects.
>
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your 
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution