Further thing you can do for me if you are compiling from source code anyway and can replicate this on dev, test or staging environments (not production), is to try using:
https://github.com/GrahamDumpleton/mod_wsgi/archive/5cf57b021a426284cd92a8fe83e2af70c84da57c.tar.gz This is from just before the commit I would suspect as introducing any issue for 4.4.1. If that works, then try: https://github.com/GrahamDumpleton/mod_wsgi/archive/fa3f9b0ca37ad6c6a9d433dbff4a8c55f6c9185a.tar.gz This is just after what is the likely problem commit. Graham On 13/12/2014, at 6:24 AM, Graham Dumpleton <[email protected]> wrote: > I need the full stack traces from gdb. > > When it crashes gives you the gdb prompt can you run: > > thread apply all bt > > Thanks. > > Graham > > On 13/12/2014, at 3:06 AM, [email protected] wrote: > >> >> I'm only seeing the problem in daemon mode. If I remove WSGIDaemonProcess >> and WSGIProcessGroup from apache cfg it works fine. >> >> Here is gdb with WSGIDaemonProcess and WSGIProcessGroup removed: >> --------------------------------------------- >> # gdb /usr/local/apache/bin/httpd >> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6) >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-redhat-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>... >> Reading symbols from /usr/local/apache/bin/httpd...done. >> (gdb) run -X >> Starting program: /usr/local/apache/bin/httpd -X >> [Thread debugging using libthread_db enabled] >> Detaching after fork from child process 11475. >> >> Program received signal SIGSEGV, Segmentation fault. >> apr_pool_cleanup_kill (p=0xff3c48, data=0x82d9f0, >> cleanup_fn=0x7ffff7bc15f0 <brigade_cleanup>) >> at memory/unix/apr_pools.c:2276 >> 2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) { >> Missing separate debuginfos, use: debuginfo-install >> glibc-2.12-1.149.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 >> krb5-libs-1.10.3-33.el6.x86_64 libcom_err-1.41.12-21.el6.x86_64 >> libselinux-2.0.94-5.8.el6.x86_64 nss-softokn-freebl-3.14.3-18.el6_6.x86_64 >> openssl-1.0.1e-30.el6_6.4.x86_64 sqlite-3.6.20-1.el6.x86_64 >> zlib-1.2.3-29.el6.x86_64 >> (gdb) quit >> A debugging session is active. >> >> Inferior 1 [process 11457] will be killed. >> >> Quit anyway? (y or n) y >> [root@centos6-02 mod_wsgi-4.4.0]# >> --------------------------------------------- >> I'm not sure what the Seg fault listed is. My app runs fine. >> >> If I add apache cfg: >> WSGIDaemonProcess debug threads=1 >> WSGIProcessGroup debug >> >> From command line: >> apachectl -k graceful >> gdb /usr/local/apache/bin/httpd <pid from virtual host error log> >> >> Then I get a 504 gateway timeout in my browser. If I quit gdb I can load >> the page. >> >> I tried apache TimeOut 600 with the same result. To create the problem I >> first refresh the admin problem, set filters and load results and submit an >> action via AJAX. I get the errors when submit via ajax. I got the 504 when >> I refresh the admin. Normally the refresh happens very quick. >> >> On Friday, December 12, 2014 12:19:47 AM UTC-5, [email protected] wrote: >> When I upgraded from 4.3.0 to 4.4.0 I've started to get errors “Truncated or >> oversized response headers received from daemon process” and seg faults. >> >> I downgraded and everything went back to working. >> >> I'm seeing this on a Django app that uses AJAX to send to a custom view in >> the admin. I've also seen this with a bot that is claiming to be Google. But >> since it is only visiting one of my sites I'm expect it's not from Google. >> >> I'm using Centos 6.6, python 2.7.8, and Apache 2.4.10. >> >> Is there a new setting I need to change or is this a bug? I didn't see >> anything in the change log that I need to change >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
