<type>documentation</type>
<domain>trouble</domain>
<id>trouble-debug-nostop-breakpoints</id>
<title>Failure to Stop on Breakpoints or Show Source Code</title>
<date>$Date$</date>
<version>$Revision$</version>
<product>per+</product>

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 
<script:show_preferences_gui#prefname="gui.auto-save-before-action">`__ 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
<script:show_preferences_gui#prefname="debug.multi-process-maximum">`__ 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 <ref:debug/debugger-limitations>`__.
 