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
>>
>>
>
