On Thu, 1 Nov 2001, Richard Chamberlain wrote:
> Can someone run the process of remote debugging for me step by step?
>> I tried it for the first time yesterday by popping a file on my isp,
> uploading the debug server and setting network passive listen. I then set a
> breakpoint ran the script and (unless I was dreaming!) it seemed to work.
> Fantastic I thought - really easy.
>> Then I couldn't get it to work again, so I read the instructions and set the
> webserver address in passivehosts - and debug.location-map, to map my local
> directory to one on the webserver. Still nothing - The debugger message
> changes, and if I set it to verbose in wingdbstub.py I can see it connects to
> me - but no breakpoints! it even mentions them in the server output.
>> What I could do with is a short example bearing in mind that I'm running it
> from a webserver.
Sounds like indeed you've got it set up right, at least in that the
connection is happening. The problem is that Wing isn't recognizing the
breakpoints as being on lines you are reaching in the code. There are
several possible reasons for this:
* If source files differ on the server from the copy Wing IDE has open,
line numbers might not match up right so it could miss a breakpoint.
This would explain why it worked the first time and not later.
* The mapping you've given for debug.location-map is flawed, so that
the file name seen on the server is wrong (you should be able to
verify that by looking at the verbose debugging output).
* Any of the limitations in section 6.16 of the manual might be coming
into play. See:
http://archaeopteryx.com/psupport/1.1/html/node7.html#SECTION007160000000000000000
One particular one to try is to make sure to invoke your script on
the web server with the full path to the script as in:
python /path/to/script/myscript.py
Instead of:
python myscript.py
There are hard-to-fix (but we're working on it!) oddities that can
arise in rare cases when you invoke without giving the full path. It's
worth ruling out those problems.
Make sure to remove *.pyc files when mucking with this, as they might
contain the partial path from a previous invocation and won't get
regenerated unless the corresponding *.py file changes.
* Or, finally, you could be running into a bug in Wing IDE.
One thing to try is to purposely place an unhandled exception in your code
and see if Wing stops at it. If you've got a catch-all handler somewhere
in your web server machinery also set Exception Mode to Always Stop.
This would show whether things are basically working. If the exception is
reached and reported in Wing, whether or not Wing can bring up the source
file for the exception location shows whether the location map is right.
(All of this is independent of the breakpoint detection machinery, so
this test also sheds light on whether there is a problem specific to
breakpoints or something more general).
If none of that helps, send me email with your preference file, listings
of disk areas on each machine, and output from a run with verbose
debugging messages turned on. I might be able to see something from that
to at least narrow down further where the problem is.
-----------------------------
Once you get the location map working right, and have some sort of decent
file sharing scheme, remote debugging can be quite nice. But it is still
somewhat tricky to set up right because there are so many pitfalls, mostly
in the location map. This is something we plan to improve in the future
with transfer of files via the debug network protocol, which would
effectively eliminate the trickier parts of setting up remote debugging.
I've added to our list the need for a small simple example that
illustrates use of wingdbstub in a remote debugging scenario. There are
examples of location maps in section 6.13.4.1 of the manual, in case you
didn't see them. But I can see the need for a more complete example.
Hope that helps.
- Stephan