Il giorno 25/ago/2011, alle ore 11:51, Yaniv Aknin ha scritto:
> Hi,
>
> On a vanilla Ubuntu 11.04 machine, I built uWSGI 0.9.8.5 and tried running
> the following command line:
> uwsgi --http 0.0.0.0:8080 --module test --grunt 1 --master 1
>
> Where in test.py I had simply:
> import uwsgi
> import sys
> def debug(s):
> sys.stderr.write(s + '\n')
>
> def application(environ, start_response):
> output = 'OK!'
>
> if 'grunt' in environ['REQUEST_URI']:
> # passing True to grunt() so the parent will keep serving the request
> if not uwsgi.grunt(True):
> debug("parent")
> output = 'Grunt!'
> else:
> debug("worker")
> # calling disconnect in the worker to disassociate the worker
> from the request
> uwsgi.disconnect()
> debug("disconnected")
> return
>
> start_response('200 OK', [])
> return [output]
>
> This causes a segmentation fault after printing "worker" and before printing
> "disconnected" on Ubuntu 11.04, but works fine on OSX. The segfault occurs in
> natty's eglibc's fclose(), called from
> plugins/python/uwsgi_pymodule.c:py_uwsgi_disconnect().
>
> Of course, if I won't call uwsgi.disconnect() in the worker, the segfault
> will not occur - but I thought that this will leave the worker keeping the
> connection with the webserver busy and will not let the parent finish the
> request and move on to other business.
>
> Before I dig deeper into the segfault, is this something I'm doing wrong with
> the grunt() and disconnect() APIs?
I always use the inverse logic, so it is the parent closing the connection and
the grunt continuing the job
By the way a segfault is always a bug, so i will investigate on this
--
Roberto De Ioris
http://unbit.it
JID: [email protected]
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
