import sys
import os
import logging
# need to add environment to apache's path for includes
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), "../../")))
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), "../")))
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), ".")))
# likewise add cherrypy/other modules
sys.path.append(os.path.abspath("/Library/Python/2.7/site-packages/"))
import requests
response = requests.get('http://www.google.com').text
Using Python 2.7.6, requests 2.7.0, and Apache under MAMP 3.0, the above code crashes. A quick look through the code using winpdb seems to suggest that actually trying to open an internet connection is what is crashing the Python process. The Apache log is not very helpful, only saying
[notice] child pid 18879 exit signal Segmentation fault (11)
While my full code uses Cherrypy 3.8 to provide the WSGI portion of the framework, I feel that it is irrelevant to the problem at hand.
Is this some known problem with requests+apache, or is it some other problem? Python crashing without any comments makes it hard for me to even think of a way to start solving this issue.
EDIT: Using pdb, I found that the program segfaults on line 1421 of urllib.py in the python standard library.
proxy_settings = _get_proxy_settings()
where _get_proxy_settings comes from _scproxy.
I still have no idea how to fix this.
It seems that this is a platform-specific bug for my version of MacOS.
Related
I have been using Linux to programm Python scripts, but now I have to make one of them work on Windows XP, and here I am a beginner. I have installed Python 3.4 in C:\Python34, and I have my Python script in E:\solidworks_xmlrpc. This script works perfectly on Linux, but on Windows I get this error message:
import xmlrpclib
ImportError: No module named "xmlrpclib"
I checked if there was an xmlrpc folder in C:\Python34\Lib and there is. I also defined PYTHONPATH and PYTHONHOME in system variables.
Anyone knows how to solve this, please?
Thank you so much.
EDIT
I deleted the content of the programm only a moment to proof:
import sys
print(sys.path)
And the cmd returned this:
['E:\\solidworks_xmlrpc', 'C:\\WINDOWS\\system32\\python34.zip', 'C:\\Python34\\
DLLs', 'C:\\Python34\\lib', 'C:\\Python34', 'C:\\Python34\\lib\\site-packages']
This is the real answer to the question:
Python 3.4 brings the library xmlrpc, which replaces old xmlrpclib.
So, if you have installed Python 3.4 on Windows and you want to use xmlrpclib (probably as a client side), don't write anymore this:
import xmlrpclib
Replace that with this line:
from xmlrpc import client
And replace every match of xmlrpc in the rest of your code with client.
I have been playing with Gevent, and I like it a lot. However I have run into a problem. Breakpoint are not being hit, and debugging doesn't work (using both Visual Studio Python Tools and Eclipse PyDev). This happens after monkey.patch_all() is called.
This is a big problem for me, and unfortunately this is a blocker for the use of gevent. I have found a few threads that seem to indicate that gevent breaks debugging, but I would imagine there is a solution for that.
Does anyone know how to make debugging and breakpoints work with gevent and monkey patching?
PyCharm IDE solves the problem. It supports gevent code debugging after you set a configuration flag: http://blog.jetbrains.com/pycharm/2012/08/gevent-debug-support/.
Unfortunately, at the moment I don't know a free tool capable of debugging gevent.
UPD: THERE IS! Now there is a community version of PyCharm.
pdb - The Python Debugger
import pdb
pdb.set_trace() # Place this where you want to drop into the python interpreter.
While debugging in VS Code,
I was getting this error:
It seems that the gevent monkey-patching is being used. Please set an
environment variable with: GEVENT_SUPPORT=True to enable gevent
support in the debugger.
To do this, in the debug launch.json settings, I set the following:
"env": {
"GEVENT_SUPPORT": "True"
},
The simplest, most dangerous solution would be to monkey patch stdin and stdout:
import gevent.monkey
gevent.monkey.patch_all(sys=True)
def my_app():
# ... some code here
import pdb
pdb.set_trace()
# ... some more code here
my_app()
This is quite dangerous since you risk stdin/stdout behaving in a strange way
during the rest of your app lifetime.
Instead you can use a library that I wrote: gtools.pdb. It minimizes
the risk to the pdb prompt only:
def my_app():
# ... some code here
import gtools.pdb
gtools.pdb.set_trace()
# ... some more code here
my_app()
Basically, what it does is tell pdb to use a non-blocking stdin and stdout for
its interactive prompt. Any running greenlets will still continue to run
in the background.
If you want to avoid the dependency, all you need to do is tell pdb to use
a gevent friendly stdin and stdout with something like this:
import sys
from gevent.fileobject import FileObjectThread as File
def Pdb():
import pdb
return pdb.Pdb(stdin=File(sys.stdin), stdout=File(sys.stdout))
def my_app():
# ... some code here
Pdb().set_trace()
# ... some more code here
my_app()
Note that with any of these solutions, you loose Key-up, Key-down pdb prompt facilites see gevent issue patching stdin/stdout.
I use Pycharm 2.7.3 currently and I too was having issues with gevent 0.13.8 breaking debugging. However when I updated to gevent 1.0rc3 I found I could debug again properly.
Sidenote:
I only just now learned that Jetbrains had a workaround with the config flag. I was getting around the problem when I needed to debug with the following hack. I honestly don't know why it worked nor what the negative consequences were. I just did a little trial and error and this happened to allow debugging to work when using grequests.
# overrides the monkeypatch issue which causes debugging in PyDev to not work.
def patch_time():
return
import gevent.monkey
gevent.monkey.patch_time = patch_time
import grequests
I've install python2.7 on my controller with linux 2.6.11 (BusyBox). I ran python2.7 - all normal. import os - all ok. But when i import libraries, which is required shared object files from python2.7\lib-dynload (import random, import io and etc) i have Segmentation fault error. What's the problem ?
If i try to rename, for instans _io.so to _io2.so then i have the following error:
The way to find out why something segfaults is to install Valgrind and run it with that. However that may not work on your controller. If you have a more powerful machine with the same architecture, or even a QEMU emulated copy of the same Linux binaries on a more powerful machine, then you could use that to do Valgrind debugging.
I'm very new to Python development, and am having a problem with one of my apps in OSX.
Technologies being used in this project
python 2.6
django
google app engine
rpx (openid)
When loading up the site on my windows app, there are no issues, but when trying to same app on OSX 10.6, I get the following issue:
ImportError at /rpx/rpx/login/
No module named _ctypes
Here's where the error is happening:
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ctypes/init.py in
#
"""create and manipulate C data types in Python"""
import os as _os, sys as _sys
version = "1.1.0"
from _ctypes import Union, Structure, Array
Any ideas? Thanks!
OS X 10.6's Python 2.6 does include ctypes by default. You can even see part of it in the error report. So if there's a problem with the installation, it's only a problem with part of ctypes. That suggests that either it was damaged somehow or that something else is interfering with some part of the ctypes internals.
Google App Engine is a prime candidate for this interference. ctypes itself is not available on Google App Engine.
It looks like this might be a specific interaction between Python 2.6, OS X, and Google App Engine. Likely the same problem would not be encountered if you actually upload your application to GAE for real deployment.
This issue has been raised in the GAE issue tracker here: http://code.google.com/p/googleappengine/issues/detail?id=985
The last comment there suggests changing your GAE preferences to use Python 2.5 (/usr/bin/python2.5) as a possible resolution to the issue on your OS X development machine.
I don't have enough rep to comment so I will make this a post.
The accepted answer is correct in that all you need to do is set the Python Path in the GAE preferences to /usr/bin/python2.5.
There is no need to download python 2.5 via macports or from the official python website.
python 2.5 is still installed in OSX 10.6, it is just not the default python interpreter. For this reason you need to tell GAE explicitly to use version 2.5.
FWIW I'm using GAE Launcher 1.4.1
I was using python 2.6.1 on my Mac OS X Snow Leopard 10.6.3.
Follow the steps bellow to solve this problem:
1) Download and install python 2.5.2: http://www.python.org/download/releases/2.5.2/
2) Run GoogleAppEngineLauncher.app
3) Open Preferences --> and change "Python Path:" to "/usr/local/bin/python2.5"
There's no reason to use python 2.6.1 because GAE uses 2.5.
via vitor...#gmail.com
The only thing that I can think of is that maybe it's not on your path. Seems unlikely, but I would check that anyways.
I recently had a site that was running perfect for months, all of a sudden it decided to dump itself for no approximate reason.
I am running django + mod_python + apache, and the system decided it was time to start ignoring the import of the pycurl library, my intial first thought was that somehow the library had become corrupted, or the paths were uncached by apache or mod_python.
After checking the paths, symbolic links, permissions and reinstalling the exact build of pycurl I am still recieving the same error. The strange thing is, is that I can load the library within python itself and run tests with no issues, but not within mod_python. I know for a fact that the paths are correctly pointed as I have checked them numerous times and updated the system cache accordingly.
Django now will not load or throw any errors, nor will apache log anything if I try and import the library it will just silently fail... I have been exploring this issue for 2 days now and have not come up with anything.
Any help would be greatly appreciated.
Just to add some here, the server has not been touched in any way since the final revision and launch.
I have checked every log that would indicate some type of attack against the server and there is nothing, the only thing that exists is request from my hosting provider which is where the error in question first started to appear.
Also the similar issue: stackoverflow.com/questions/1099981/… - does not work in this case.
Incase anyone is wondering the versions are as follows
Python 2.4.3
Mod_Python 3.2.8
Apache 2.2.3
Redhat Red Hat Enterprise Linux Server release 5.4
Linux Kernal 2.6.18-128.7.1.el5 x86_64
If the problem is a failing import when running under Apache but the import works when running from your login shell, double-check that there isn't a directory/file permission problem with the failing module(s). They must be read-accessible and in some cases also execute-accessible from the user id that Apache is running under.
The httpd process could be running into the open file limit; see help ulimit in bash for the relevant option to change.
Well now ... I have debugged this issue ... and the answer is quite surprising.
R**kspace decided to do a few updates to the box, updating the dependent library in question and it caused the issues ... after reinstalling the library it would try to load the c module and it was not a comp version with the current pycurl ... and they couldn't figure this out themselves for 2 days.