thanks , disable threads seems works. so, IF it's caused by some sort of race condition, does it more likely occurred while running with low max-request against lots of threads? It's very confused that this segfault definetly happens with attached config.xml on our servers.
2013/1/19 <[email protected]> > Send uWSGI mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of uWSGI digest..." > > > Today's Topics: > > 1. Re: is this a critical bug or what? (Roberto De Ioris) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Jan 2013 12:22:24 +0100 > From: "Roberto De Ioris" <[email protected]> > To: "uWSGI developers and users list" <[email protected]> > Subject: Re: [uWSGI] is this a critical bug or what? > Message-ID: > <[email protected]> > Content-Type: text/plain;charset=utf-8 > > > > hi,guys > > i encounter an segfault with uwsgi.1.4.4 + python 2.7.3 , backtrace as > > follow: > > #0 0x0000003549079a14 in strncpy () > > #1 0x00000000004622ad in init_uwsgi_app (loader=1, arg1=0xb43b730, > > wsgi_req=0x2ab1752bf060, interpreter=0xb43f120, app_type=0) > > #2 0x000000000046009f in uwsgi_python_init_apps () > > #3 0x0000000000452ca3 in uwsgi_init_all_apps () > > #4 0x0000000000451f2d in uwsgi_start (v_argv=0xb42e460) > > #5 0x0000000000450809 in main (argc=2, argv=0x7fffc0bbe9a8, > > envp=0x7fffc0bbe9c0) > > > > > > > > After detailed analyzing, this might arised under "lazy" + "vhost" > > +"max_requests". > > > > While run as vhost, each procedure in uwsgi_request_wsgi() will free > > wsgi_req -> appid, that will be visited in an other process, if it > exceeds > > maxrequests, and in the later, this appid is neither reset nor checked > > before strncpy! > > > > (Is appid_len reset to zero needed, after free(wsgi_req -> appid)? ) > > > > > > here is my config.xml > > > > > > <uwsgi> > > <id>app001</id> > > <socket>127.0.0.1:9999</socket> > > <module>webapp:default_action</module> > > <master /> > > <vhost /> > > <stats>:5050</stats> > > <pidfile2>/home/yuanfu.zzy/tmp/uwsgixxx.pid</pidfile2> > > <cache>3000</cache> > > <!-- > > <daemonize2>/home/yuanfu.zzy/tmp/wxupgrade/uwsgi.log</daemonize2> --> > > <max-requests>100</max-requests> > > <processes>4</processes> > > <threads>10</threads> > > <enable-threads/> > > <reload-mercy>4</reload-mercy> > > <lazy>true</lazy> > > <!--no-default-app/--> > > </uwsgi> > > > > again, i've tried higher max-requests, 100 just to boost the crash. > > and here is webapp.py > > > > def default_action(env, start_response): > > status_code = '200 OK' > > response_headers = [("Content-Type", 'text/html; charset=utf-8')] > > response_body = 'ok' > > start_response(status_code, response_headers) > > return [response_body] > > > > > > sorry for my poor writing, not my native language though... > > and any advice is appreciated! > > > Can you retry disabling threads ? > > sadly i cannot reproduce the problem, so it could be some kind of race > condition > > -- > Roberto De Ioris > http://unbit.it > > > ------------------------------ > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > > End of uWSGI Digest, Vol 40, Issue 21 > ************************************* >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
