<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.

**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>`__.
 