Segmentation fault with basic Django example

[WSGI Newbie]

I've just started looking at wsgi and django and following this example from Kevan Stannard.

I'm not on ubuntu, but red-hat and building everything from source (several times now!)

Red Hat Enterprise Linux Server release 5.6 (Tikanga)
uname -m = x86_64
uname -r = 2.6.18-238.el5
uname -s = Linux
uname -v = #1 SMP Sun Dec 19 14:22:44 EST 2010

Apache HTTPD 2.4.1
Python 2.7.2
Django 1.3.1
mod_wsgi 3.3

The first example (with django) from Kevan blog works, the second (using django) fails with a segmentation fault. Here's the apache error log ...

[Wed Mar 21 13:24:44.255485 2012] [authz_core:debug] [pid 6335:tid 1115105600] mod_authz_core.c(783): [client xx.xx.xx.xx:35861] AH01626: authorization result of Require all granted: granted
[Wed Mar 21 13:24:44.255523 2012] [authz_core:debug] [pid 6335:tid 1115105600] mod_authz_core.c(783): [client xx.xx.xx.xx:35861] AH01626: authorization result of <RequireAny>: granted
[Wed Mar 21 13:24:44.255631 2012] [authz_core:debug] [pid 6335:tid 1115105600] mod_authz_core.c(783): [client xx.xx.xx.xx:35861] AH01626: authorization result of Require all granted: granted
[Wed Mar 21 13:24:44.255650 2012] [authz_core:debug] [pid 6335:tid 1115105600] mod_authz_core.c(783): [client xx.xx.xx.xx:35861] AH01626: authorization result of <RequireAny>: granted
[Wed Mar 21 13:24:44.280041 2012] [:info] [pid 6431:tid 1125734720] mod_wsgi (pid=6431): Create interpreter 'hello.djangoserver|'.
[Wed Mar 21 13:24:44.282116 2012] [core:error] [pid 6335:tid 1115105600] [client xx.xx.xx.xx:35861] Invalid status line from script 'django.wsgi': Status
[Wed Mar 21 13:24:44.283219 2012] [core:error] [pid 6335:tid 1115105600] [client xx.xx.xx.xx:35861] End of script output before headers: django.wsgi
[Wed Mar 21 13:24:44.645908 2012] [core:notice] [pid 4267:tid 47419419049888] AH00052: child pid 6431 exit signal Segmentation fault (11)
[Wed Mar 21 13:24:44.645939 2012] [:info] [pid 4267:tid 47419419049888] mod_wsgi (pid=6431): Process 'hello.djangoserver' has died, deregister and restart it.
[Wed Mar 21 13:24:44.645949 2012] [:info] [pid 4267:tid 47419419049888] mod_wsgi (pid=6431): Process 'hello.djangoserver' has been deregistered and will no longer be monitored.
[Wed Mar 21 13:24:44.646526 2012] [:info] [pid 6474:tid 47419419049888] mod_wsgi (pid=6474): Starting process 'hello.djangoserver' with uid=48, gid=48 and threads=1.
[Wed Mar 21 13:24:44.646939 2012] [:info] [pid 6474:tid 47419419049888] mod_wsgi (pid=6474): Initializing Python.
[Wed Mar 21 13:24:44.676237 2012] [:info] [pid 6474:tid 47419419049888] mod_wsgi (pid=6474): Attach interpreter ''.
[Wed Mar 21 13:24:44.676948 2012] [:debug] [pid 6474:tid 1135319360] mod_wsgi.c(10828): mod_wsgi (pid=6474): Started thread 0 in daemon process 'hello.djangoserver'.


Any suggestions appreciated, thanks!

W.N.

[Graham Dumpleton]

If you are only running the one Django site, try setting in VirtualHost:

WSGIApplicationGroup %{GLOBAL}

The issue you might be hitting is a third party C extension module for
Python being used not being safe to use in a sub interpreter.

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Other options are that you have mod_python loaded at same time and it
is trying to use conflicting Python version.

Graham

> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/modwsgi/-/61ZVdWeQj-IJ.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to
> modwsgi+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.

[WSGI Newbie]

Thanks for the information Graham, unfortunately this has had no effect. I'm currently getting away with commenting out the Daemon related directives, but can't remember now why I put them in in the first place!

I managed to get the following information out of a core file (I'm no expert with gdb so any pointers to more useful info appreciated)

Core was generated by `(wsgi:cfServer)              -k restart'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000036422cb2e6 in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x00000036422cb2e6 in poll () from /lib64/libc.so.6
#1  0x00002b504c342c02 in apr_poll () from /usr/local/lib/libapr-1.so.0
#2  0x00002b504f8236d3 in wsgi_daemon_main (p=0xb373138, daemon=0xb48ef88)
    at mod_wsgi.c:11330
#3  0x00002b504f82551f in wsgi_start_process (p=0xb373138, daemon=0xb48ef88)
    at mod_wsgi.c:11969
#4  0x00002b504f825f50 in wsgi_start_daemons (pconf=0xb373138,
    ptemp=<value optimized out>, plog=<value optimized out>,
    s=<value optimized out>) at mod_wsgi.c:12181
#5  wsgi_hook_init (pconf=0xb373138, ptemp=<value optimized out>,
    plog=<value optimized out>, s=<value optimized out>) at mod_wsgi.c:13755
#6  0x0000000000452412 in ap_run_post_config ()
#7  0x00000000004290c5 in main ()
(gdb)

I also used one of Graham's alternate wsgi scripts to get this environment information ...

[25.148430]('REQUEST',
[25.148869] {'CONTEXT_DOCUMENT_ROOT': '/srv/www/wsgi',
[25.148904]  'CONTEXT_PREFIX': '',
[25.148933]  'DOCUMENT_ROOT': '/srv/www/wsgi',
[25.148960]  'GATEWAY_INTERFACE': 'CGI/1.1',
[25.148989]  'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
[25.149018]  'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7',
[25.149077]  'HTTP_ACCEPT_ENCODING': 'gzip,deflate',
[25.149107]  'HTTP_ACCEPT_LANGUAGE': 'en-us,en;q=0.5',
[25.149134]  'HTTP_CACHE_CONTROL': 'max-age=0',
[25.149161]  'HTTP_CONNECTION': 'keep-alive',
[25.149188]  'HTTP_HOST': 'wsgi.djangoserver',
[25.149215]  'HTTP_KEEP_ALIVE': '115',
[25.149244]  'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Red Hat/3.6-2.el5 Firefox/3.6.13',
[25.149273]  'LD_LIBRARY_PATH': '/usr/local/apache2/lib:',
[25.149300]  'PATH_INFO': '/',
[25.149327]  'PATH_TRANSLATED': '/srv/www/wsgi/app.wsgi/',
[25.149354]  'QUERY_STRING': '',
[25.149380]  'REMOTE_ADDR': 'xx.xx.xx.xx',
[25.149407]  'REMOTE_PORT': '48157',
[25.149433]  'REQUEST_METHOD': 'GET',
[25.149460]  'REQUEST_SCHEME': 'http',
[25.149486]  'REQUEST_URI': '/',
[25.149512]  'SCRIPT_FILENAME': '/srv/www/wsgi/app.wsgi',
[25.149539]  'SCRIPT_NAME': '',
[25.149566]  'SERVER_ADDR': 'xx.xx.xx.xx',
[25.149592]  'SERVER_ADMIN': 'root@localhost',
[25.149619]  'SERVER_NAME': 'wsgi.djangoserver',
[25.149659]  'SERVER_PORT': '80',
[25.149688]  'SERVER_PROTOCOL': 'HTTP/1.1',
[25.149715]  'SERVER_SIGNATURE': '',
[25.149745]  'SERVER_SOFTWARE': 'Apache/2.4.1 (Unix) OpenSSL/0.9.8e-fips-rhel5 mod_wsgi/4.0-TRUNK Python/2.7.2 mod_fcgid/2.3.6',
[25.149774]  'mod_wsgi.application_group': 'wsgi.djangoserver|',
[25.149802]  'mod_wsgi.callable_object': 'application',
[25.149828]  'mod_wsgi.enable_sendfile': '0',
[25.149855]  'mod_wsgi.handler_script': '',
[25.149882]  'mod_wsgi.input_chunked': '0',
[25.149919]  'mod_wsgi.listener_host': '',
[25.149947]  'mod_wsgi.listener_port': '80',
[25.149973]  'mod_wsgi.process_group': '',
[25.150000]  'mod_wsgi.queue_start': '1332345685147562',
[25.150027]  'mod_wsgi.request_handler': 'wsgi-script',
[25.150060]  'mod_wsgi.script_reloading': '1',
[25.150137]  'mod_wsgi.version': (4, 0),
[25.150175]  'wsgi.errors': <mod_wsgi.Log object at 0x2aaaaab244b0>,
[25.150209]  'wsgi.file_wrapper': <type 'mod_wsgi.FileWrapper'>,
[25.150244]  'wsgi.input': <mod_wsgi.Input object at 0x2aaaaab24630>,
[25.150276]  'wsgi.multiprocess': True,
[25.150306]  'wsgi.multithread': True,
[25.150336]  'wsgi.run_once': False,
[25.150363]  'wsgi.url_scheme': 'http',
[25.150435]  'wsgi.version': (1, 0)})
[25.150530]('RESPONSE',
[25.150555] '200 OK',
[25.150710] [('Content-type', 'text/plain'), ('Content-Length', '12')])

Although this was without the Daemon directive. I also noted that the content of the wsgi script file is irrelevant (an empty file causes the same behaviour)

Regards, W.N.

On Thursday, 22 March 2012 05:21:32 UTC, Graham Dumpleton wrote:

If you are only running the one Django site, try setting in VirtualHost:

  WSGIApplicationGroup %{GLOBAL}

The issue you might be hitting is a third party C extension module for
Python being used not being safe to use in a sub interpreter.

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Other options are that you have mod_python loaded at same time and it
is trying to use conflicting Python version.

Graham

[Graham Dumpleton]

Sorry for slow reply, cleaning up inbox.

In your output you have:

'mod_wsgi.application_group': 'wsgi.djangoserver|',

This shows that for that example at least WSGIApplicationGroup was not
set to %{GLOBAL} as directed.

If you are only running the one app, you should set application group
to the main interpreter using that regardless of whether using
embedded or daemon, it is the safest thing to do.

Graham

> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/modwsgi/-/XbOeqzT4aTYJ.