Hello, Sorry for the delay, Here is the version of apache and mod_wsgi: Apache/2.2.14 (Ubuntu) mod_wsgi/2.8 Other packages installed : mod_fastcgi/2.4.6 mod_jk/1.2.28 PHP/5.3.2-1ubuntu4.24 with Suhosin-Patch mod_ssl/2.2.14 OpenSSL/0.9.8k Python/2.6.5 Otherwise , I'll create a new case in mod_wsgi mailing list.
Regards 2014-07-17 13:32 GMT+00:00 Graham Dumpleton <grah...@apache.org>: > Since you don't say what version of mod_wsgi you are using, or what > version of Apache, then the only other thing I can suggest right now is to > ensure that you are using the latest mod_wsgi version. > > The latest version of mod_wsgi is version 4.2.6. Pretty well all Linux > distributions are still shipping version 3.3. > > Older versions may exhibit segmentation faults with Apache 2.4 in some > situations, although this is generally only on process shutdown and I have > never heard of mod_wsgi itself to cause a hang when using Apache 2.4, > although lxml is very much known to in some cases. > > Either way, please take this discussion now to the mod_wsgi mailing list > as described in the mod_wsgi documentation. > > > http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions > > When you post to the mod_wsgi mailing list, please provide proper Apache > and mod_wsgi version details as described in: > > > http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Apache_Build_Information > > http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Apache_Modules_Loaded > > As well as results of verifying Python installation in use: > > > http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library > > http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use > > and confirmation that your application is indeed running in the main > interpreter and daemon mode. > > > http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode > > http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used > > See you in the mod_wsgi mailing list. > > Graham > > > On 17 July 2014 01:32, Elhadi Falah <hadi.fa...@gmail.com> wrote: > >> Hello, >> >> I use mod_wsgi to run processes and not mod_python. >> >> WSGIDaemonProcess p1 threads=25 >> python-path=/opt/appengine/google_appengine:/opt/appengine/google_appengine/lib/django:/opt/appengine/google_appengine/lib/webob:/opt/appengine/google_appengine/lib/yaml/lib >> WSGIProcessGroup p1 >> >> WSGIScriptAlias / /var/www/application/rep/handler.wsgi >> >> I already used the directive WSGIApplicationGroup %{GLOBAL} to run un >> the main interpreter context but the issue persists after executing apache >> graceful or reload. >> >> Regards >> >> >> >> 2014-07-16 13:44 GMT+00:00 Graham Dumpleton <grah...@apache.org>: >> >> It is well known that the lxml package doesn't work properly in a Python >>> sub interpreter context. Force it to run in the main interpreter context. >>> >>> See: >>> >>> >>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API >>> >>> In other words look at using: >>> >>> WSGIApplicationGroup %{GLOBAL} >>> >>> as documented. >>> >>> Graham >>> >>> >>> On 16 July 2014 03:11, Elhadi Falah <hadi.fa...@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> We are using lxml in several of our applications with Python 2.6 and >>>> from time to time, the application stops responding after a segmentation >>>> fault error ( [notice] child pid 10544 exit signal Segmentation fault >>>> (11)), and this kind of backtrace: >>>> >>>> Jul 1 15:24:48 server1 httpd: *** glibc detected *** /usr/sbin/apache2: >>>> munmap_chunk(): invalid pointer: 0x00007f6468bf2c00 *** >>>> >>>> Jul 1 15:24:48 server1 httpd: ======= Backtrace: ========= >>>> >>>> Jul 1 15:24:48 server1 httpd: /lib/libc.so.6(+0x78bf6)[0x7f64767ecbf6] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/libxml2.so.2(xmlCopyError+0xd1)[0x7f6473311801] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/libxml2.so.2(__xmlRaiseError+0x30b)[0x7f6473312ecb] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/libxml2.so.2(+0x393e5)[0x7f64733173e5] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/libxml2.so.2(xmlParseDocument+0x2dc)[0x7f647332e5cc] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/libxml2.so.2(+0x50895)[0x7f647332e895] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8cbc2)[0x7f645691cbc2] >>>> >>>> Jul 1 15:24:48 server1 httpd: >>>> /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x2c7cf)[0x7f64568bc7cf] >>>> >>>> After trying several versions of lxml we are still facing the >>>> issue.I've checked for the system memory consumption but everything looks >>>> fine to me, plenty of memory available, I don't see any process consuming >>>> abnormally. >>>> >>>> The issue is reproducible everytime when we execute the commande apache >>>> (apache2 reload or apache2 graceful). As workaround for this issue we >>>> execute apache2 restart. >>>> >>>> We've followed recommendations defined on these 2 links but we're still >>>> facing the issue. >>>> >>>> >>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API >>>> >>>> >>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Multiple_Python_Sub_Interpreters >>>> >>>> Library version: >>>> >>>> print("%-20s: %s" % ('Python', sys.version_info)) >>>> >>>> Python : (2, 6, 5, 'final', 0) >>>> >>>> print("%-20s: %s" % ('lxml.etree', etree.LXML_VERSION)) >>>> >>>> lxml.etree : (2, 3, 5, 0) >>>> >>>> print("%-20s: %s" % ('libxml used', etree.LIBXML_VERSION)) >>>> >>>> libxml used : (2, 7, 6) >>>> >>>> print("%-20s: %s" % ('libxml compiled', >>>> etree.LIBXML_COMPILED_VERSION)) >>>> >>>> libxml compiled : (2, 7, 6) >>>> >>>> print("%-20s: %s" % ('libxslt used', etree.LIBXSLT_VERSION)) >>>> >>>> libxslt used : (1, 1, 26) >>>> >>>> print("%-20s: %s" % ('libxslt compiled', >>>> etree.LIBXSLT_COMPILED_VERSION)) >>>> >>>> libxslt compiled : (1, 1, 26) >>>> >>>> Apache 2.2.14 >>>> >>>> Here is the source code that generate the issue: >>>> >>>> ID_TRANSFORM = >>>> os.environ['APPLICATION_WORKING_PATH']+'/statics/xsl/list.xsl' >>>> >>>> styledoc = lxml.etree.parse(ID_TRANSFORM) >>>> >>>> transform = lxml.etree.XSLT(styledoc) >>>> >>>> doc_root = lxml.etree.XML(str(atom)) >>>> >>>> Could you help us on this case? >>>> >>>> Regards >>>> >>>> >>> >> >
