Using WingIDE to debug a web application, I have set a breakpoint in some Python code which runs when a web-form is submitted. Just before the breakpoint I have inserted 'import wingdbstub' to activate remote deubgging. However, execution does not stop at the breakpoint. I know the code is running because if I insert 'raise exception(sys.modules)' just before the breakpoint, execution stops and a traceback appears in my browser, showing wingdbstub is loaded.
If I hover over the bug icon in the status-bar, a dialog says "No debug process / listening for connections on TCP/IP 50005. Allowed hosts 127.0.0.1". I know I have 'lost' debug mode when a) the bug icon changes from green to white, and b) the debugging toolbar buttons (step into, over, out, etc.) disappear.
I tried deleting compiled .pyc files so that they recompile when the module next runs, but the problem remains.
How can I check if Wing is listening on the correct port? The strange thing is that remote-debugging has worked sometimes, but most of the time it doesn't.
Any help would be appreciated. For the record, I am using Python 3.1, CherryPy 3.20 and WingIDE Personal 3.2.11.
Alan
Under Windows, I've experienced the same behavior you mention, i.e., remote debugging sometimes works, but often 'gets stuck'. I've found a few things helpful in resolving this situation:
Make sure your firewall isn't blocking traffic to/from the ports being used by WingIDE and the process being debugged. (In my case, I had to unblock both wing.exe and the program I was attempting to debug in Windows Firewall.)
Make sure you haven't accumulated any zombie python processes after failed debug sessions. These can hold open a connection to the IDE, making it impossible for a newly-spawned instance to connect. (Under Windows, you can use the tasklist command to check for running python instances, and netstat -anp tcp will show any sockets stuck in the TIME_WAIT state.)
Insert a time.sleep(10) call immediately after your import wingdbstub statement. Start the program from a console, make sure it connects in the IDE (debug icon will turn green), then hit the 'Pause' button in the IDE, followed by 'Step Out'. (I can't begin to explain why, but this appeared to right the ship for me a couple of times after the debug connection had gone wonky.)
The above advice probably applies to Linux as well, but I've only experienced this problem under Windows so far...
Related
I run Python code on a remote machine (which I ssh into) and then use Tmux. The code runs fine UNTIL I disconnect from the remote machine. The whole point of my connecting via Tmux is so that the code continues to run even when I'm not connected to the remote machine. When I reconnect later, I have the error message:
: cannot connect to X server localhost:11.0
Does anyone have an idea why this is happening or how I can stop it?
cannot connect to X server localhost:11.0
...means that your code is trying (and failing) to connect to an X server -- a GUI environment -- presumably being forwarded over your SSH session. tmux provides session continuity for terminal applications; it can't emulate an X server.
If you want to stop it from being able to make any GUI connection at all (and perhaps, if the software is thusly written, from even trying), unset the DISPLAY environment variable before running your code.
If this causes an error or exception, the code generating that is the same code that's causing your later error.
If you want to create a fake GUI environment that will still be present, you can do that too, with Xvfb.
Some Linux distributions provide the xvfb-run wrapper, to automate setting this up for you:
# prevent any future commands in this session from connecting to your real X environment
unset DISPLAY XAUTHORITY
# run yourcode.py with a fake X environment provided by xvfb-run
xvfb-run python yourcode.py
By the way, see the question xvfb-run unreliable when multiple instances invoked in parallel for notes on a bug present in xvfb-run, and a fix available for same.
If you want an X server you can actually detach from and reattach to later, letting you run GUI applications with similar functionality to what tmux gives you for terminal applications, consider using X11vnc or a similar tool.
I want to use eclipse, pydev to remote debug my python script. Python script is on a remote Ubuntu server, and Eclispe/pydev is running on my Windows 7 machine.
I followed every step according to this one.
http://pydev.org/manual_adv_remote_debugger.html
The problem is in the last step of configuring path in pydevd_file_utils.py on server, it does not recognize the change. This is what I changed:
PATHS_FROM_ECLIPSE_TO_PYTHON = [(r'c:\EZ_Green\plugins', r'/home/jiechao/EZ_Green/plugins')]
When I run the script, it gives me such error.
pydev debugger: warning: trying to add breakpoint to file that does not exist: /home/jiechao/EZ_Green/plugins/D:/EZ Green/backend/getData.py (will have no effect)
Seems the change does not apply, has anyone done this before or have any ideas?
Thanks a lot
-----------------update 1--------------
So I solve the previous problem and now here is the new problem.
This is the output of program, and it seems the path configuration is correct.
Debug Server at port: 5678
pydev debugger: replacing to server: D:\EZ Green\Product\EZ_Green\plugins\test.py
pydev debugger: sent to server: /home/jiechao/EZ_Green/plugins\test.py
pydev debugger: replacing to client: /home/jiechao/EZ_Green/plugins/test.py
pydev debugger: sent to client: D:\EZ Green\Product\EZ_Green\plugins/test.py
But eclipse does not stop at the breakpoint, not even at pydevd.settrace()
I have no idea why it does not stop.
When I use remote debug on local machine, it works pretty well. When I want to debug on a remote server machine, it does not work. I don't know what's the problem.
------------------update 2---------------------
Problem solved. The script on my client and server turns out to be a little different. So I did not see the breakpoint it stopped.
I am so stupid!
Thanks anyway.
Even though it is possibly not the exact approach you may expect,
one option is to start the Unittest from the command line and attach the debugger by RemoteDebugServer via 'pydevd.py'.
This is now a fully automated option of ePyUnit which includes the automation of remote debugging with PyDev and Eclipse by 'pydevd.py'. This works seamlessly for 'subprocesses' as well as independently started command line processes.
The hostame and the port number could be varied as required, default is
localhost:5678.
See:
https://pypi.python.org/pypi/epyunit
https://pythonhosted.org/epyunit/
For basics of remote debugging:
http://www.pydev.org/manual_adv_remote_debugger.html
Also enhanced unittest integration into PyUnit.
Comments and fixes are welcome.
Have fun.
I wrote a simple HTTP server in python to manage a database hosted on a server via a web UI. It is perfectly functional and works as intended. However it has one huge problem, it won't stay put. It will work for an hour or so, but if left unused for long periods of time when returning to use it I have to re-initialize it every time. Right now the method I use to make it serve is:
def main():
global db
db = DB("localhost")
server = HTTPServer(('', 8080), MyHandler)
print 'started httpserver...'
server.serve_forever()
if __name__ == '__main__':
main()
I run this in the background on a linux server so I would run a command like sudo python webserver.py & to detach it, but as I mentioned previously after a while it quits. Any advice is appreciated cause as it stands I don't see why it shuts down.
You can write a UNIX daemon in Python using the python-daemon package, or a Windows service using the pywin32.
Unfortunately, I know of no "portable" solution to writing daemon / service processes (in Python, or otherwise).
Here's one piece of advice in a story about driving. You certainly want to drive safely (figure out why your program is failing and fix it). In the (rare?) case of a crash, some monitoring infrastructure, like monit, can be helpful to restart crashed processes. You probably wouldn't want to use it to paper over a crash just like you wouldn't want to deploy your air bag every time you stopped the car.
Well, first step is to figure out why it's crashing. There's two likely possibilities:
The serve_forever call is throwing an exception.
The python process is crashing/being terminated.
In the former case, you can make it live forever by wrapping it in a loop, with a try-except. Probably a good idea to log the error details.
The latter case is a bit trickier, because it could be caused by a variety of things. Does it happen if you run the script in the foreground? If not, maybe there's some kind of maintenance service running that is terminating your script?
Not really a complete answer, but perhaps enough to help you diagnose the problem.
Have you tried running it from inside a screen session?
$ screen -L sudo python webserver.py
As an alternative to screen there is NoHup which will ensure the process carries on running after your logged out.
Its worth checking the logs to see why its killed/quitting as well as it may not be related to the operating system but an internal fault.
I use IDEA 10.5 for my Flask experimentation. Flask has en embedded test server (like Django does)
When I launch my test class, the dev server launches as well on port 5000. All good.
* Running on http://127.0.0.1:5000/
When I click on the "Stop process" button (red square), I get the message saying the process is finished :
Process finished with exit code 143
However the server is still alive (responds to requests) and I can see I still have a python process running.
Obviously this prevents me from relaunching the test straight away, I have to kill the server process first.
How do you manage to get both your program and the server ending at the same time ?
I guess what happens is that you start your flask app which then is forking the development server as a new process. If you stop the app the forked process is still running.
This looks like a problem, that cannot easily be solved within the means of your IDE. You could add something to your main to kill the already running server process, before starting the app again, but that seems ugly.
But why don't you just start your app with app.run(debug=True) as described in flask doc? The server will reload automatically everytime you changed your app so you don't have to stop and restart it manually.
EDIT:
Something a bit quirky just came to my mind: if you just need a comfortable way to kill the server from within the IDE all you have to do is to introduce a syntactical error in one of the places the reloader monitors, save the file and the server will choke on it and die :)
This doesn't happen anymore with newer versions (tested with PyCharm 2.0)
In Gnome, whenever an application is started, the mouse cursor changes from normal to an activity indicator (a spinning wheel type thing on Ubuntu). Is there any way to inform Gnome (through some system call) when the application has finished launching so that the mouse cursor returns to normal without waiting for the usual timeout of 30 seconds to occur.
I have a program in Pythong using GTK+ that is showing the icon even after launching, so what system call do I make?
Normally it happens automatically when you open the application's window.
It may be that the application's launcher just calls an already running instance, in that case it won't be automatically detected. The call you need then is this:
import gtk
gtk.gdk.notify_startup_complete()
Your application can opt out of startup notification by adding
StartupNotify=false
to your application's .desktop file.
Of course, it is friendlier to leave it enabled and participate in startup notification.
I had a similar issue with an application I wrote. I was launching the application through a shell script containing the line
python /path/to/application.py
This launched the application as I expected, but the startup notification did not stop.
It worked correctly once I changed the content of my script to this:
exec "/usr/bin/python" "/path/to/application.py"
Obviously the latter one seems to be the correct way to launch the application, though I don't have enough insight to tell why.
This normally happens automatically when calling the gtk.main() function