> With rapier wit and elegant prose, Roberto De Ioris wrote: >> >> > All, >> > >> > I'm getting a sporadic double-free on my uwsgi setup: >> > >> > read(): Success [proto/http.c line 272] >> > Tue Jan 31 04:07:18 2012 - error parsing request >> > *** glibc detected *** bin/uwsgi: double free or corruption (!prev): >> > 0x09101880 *** >> > Tue Jan 31 05:36:12 2012 - *** uWSGI listen queue of socket 3 full !!! >> > (100/100) *** >> > Tue Jan 31 05:36:13 2012 - *** uWSGI listen queue of socket 3 full !!! >> > (100/100) *** >> > Tue Jan 31 05:36:14 2012 - *** uWSGI listen queue of socket 3 full !!! >> > (100/100) *** >> > Tue Jan 31 05:36:15 2012 - *** uWSGI listen queue of socket 3 full !!! >> > (100/100) *** >> > ... these continue until uwsgi is restarted ... >> > >> > The setup is a varnish cache ( varnishd (varnish-3.0.2 revision >> cbf1284) >> > ) pointing directly at a uwsgi (uWSGI 1.0.2.1) http-socket on a >> separate >> > host. >> > Both hosts are 32-bit Linodes running Ubuntu Lucid. >> > >> > From what I can see trying to compare timestamps in the varnish logs >> vs. >> > the uwsgi log, it looks like the request that is triggering the >> > double-free is a POST, although there's enough traffic that I'm not >> 100% >> > certain of this. >> > >> > Anyone else seen something like this? Any additional diagnostics that >> > would be helpful in tracking it down? >> > >> > Thanks in advance! >> > >> > dave >> > >> > >> >> Can you paste the full uWSGI config ? > > <uwsgi> > <http-socket>192.168.159.92:3100</http-socket> > <master/> > <processes>4</processes> > <env>DJANGO_SETTINGS_MODULE=bbt.settings_prod</env> > <virtualenv>/home/bbt/bandbacktogether</virtualenv> > <pythonpath>/home/bbt/bandbacktogether</pythonpath> > <module>bbt.wsgi</module> > <logto>bbt.log</logto> > <uid>bbt</uid> > <gid>bbt</gid> > </uwsgi> > > >> >> It is a bug for sure but i dot not get why the master process does not >> respawn your worker after the double free >> > > I just searched the log a different way and discovered that there are > instances where the worker does restart after the crash. In every > instance where the worker does not restart, however, it is the listen > queue of socket 3 that fills up -- maybe there's an off-by-one somewhere > that misses that last worker in the list? > > Thanks for your help! >
This has been fixed in uwsgi-1.0 tree https://projects.unbit.it/hg/uwsgi-1.0/rev/6a0b8d59e9df you can take the current tip (or directly the patch), or wait til the week-end for an official release Many thanks for your report (the bug was really in the POST handling, it happens when you do not send enough data in respect of Content_length header) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
