Failure to Stop on Breakpoints or Show Source Code
There are several reasons why Wing may fail to stop on breakpoints or fail to show the Python source code when an exception is reached:
Not saving before you run in the debugger causes the debugger to run with the copy of the file that is on disk, while breakpoints are set using the edited copy of the file in the editor. If lines don't match up, then breakpoints will be missed. To avoid this problem, enable the File > Auto-Save Files Before Debug or Execute preference.
Debugging multi-process code can be a problem if child processes are started and not automatically debugged. This is commonly a problem when using Flask, Django, and other frameworks that implement auto-reload by managing and restarting a child process. Debugging child processes is only possible in Wing Pro, and is off by default. To enabled it, set Debug Child Process under the Debug/Execute tab in Project Properties to Always Debug Child Processes.
Importing a module before debug has started will appear to miss breakpoints at the top level of the module when it is imported again after debug has started, because the top level of the module is evaluated only during the first import. This occurs with some Python standard library modules that the debugger loads before starting user code, and may occur with any modules loaded before debug is started with wingdbstub.
Storing incorrect file names in ``*.pyc`` files prevents the debugger from identifying which breakpoints are relevant. This can be caused by using partial path names on the Python Path or when invoking a script from the command line, moving around the *.pyc file after they are created, or using compileall.py to create *.pyc files from source. The easiest way to solve this is to use only full paths on Python Path and remove any problematic *.pyc files so they can be regenerated.
Failing to send file names to compile() results in code objecs with co_filename set to <string>, which makes it impossible to determine which breakpoints are relevant. This is seen fairly often in embedded Python implementations, where Python acts as a scripting language in a larger application. A work-around is to set __file__ in the module to the correct full path to the source code, although it's better to fix how compile() is being used.
Too many debug processes may cause Wing to fail to stop on breakpoints because it can only debug a finite number of processes at a time. The number of processes that Wing can debug concurrently is 1 in Wing 101 and Wing Personal and set with the Debugger > Processes > Maximum Process Count preference in Wing Pro.
Other less common problems include running Python with psyco or other optimizer, overriding the Python __import__ routine, adding breakpoints after you've started debugging an application that spends much of its time in non-Python code, and using symbolic links on Windows.
For more information, see Debugger Limitations.
