[wingide-users] remote debuggingStephan R.A. Deibel firstname.lastname@example.org
Thu, 1 Nov 2001 18:28:46 -0500 (EST)
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 184.108.40.206 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
Run by Mailman v 2.0.8
Copyright (c) 2000-2002, Archaeopteryx Software, Inc.