Bug #62399 Scripting shell deadlock when breakpoints are set in mform applications

• Submitted: 9 Sep 2011 19:10
• Modified: 15 Sep 2011 14:59
• Reporter: Gary Su
• Status: Won't fix
• Category: MySQL Workbench
• Severity: S2 (Serious)
• Version: 5.2.34CE
• OS: Windows (Windows 7 32bit)
• CPU Architecture: Any

[9 Sep 2011 19:10] Gary Su

Description:
If a breakspoint is set for Python code of a mform application and it is hit in the Scripting Shell(SS), the thread does not return back to SS. As a result, the developer can not release the breakpoint in SS and the form can not function due to the breakpoint. The system is in a deadlock situation and the only way to get out is to crash WB from the task manager.

How to repeat:
Convert the auto_create_fks Python code to script and bring it up in the SS. Set a break point in any statement within the findMatches function. Run the Python script. A form will appear. Click on the "Preview Matches" button. The SS console will display "breakpoint hit." At this point, the form is still in control but it can do anything due to the breakpoint. However, the developer can't check the variables in SS or release the breakpoint. 

Suggested fix:
When SS hits a breakpoint, it should gain control or there should be a way for it to gain control.

[15 Sep 2011 14:59] Alfredo Kojima

Hi Gary

The problem you describe is a known issue, but we have no acceptable solution for it at the moment because of the way the debugger and mforms support in WB are implemented, so debugging mforms 
code in the Scripting shell is not fully supported, even though we understand it limits the usefulness 
of the debugger quite a lot. Once we find out a good solution (we have some ideas, but nothing concrete
yet) and time to implement it, we will revisit this issue, but for now I'll close it as Won't fix.