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!
--
d.w. harks <[email protected]> | http://about.me/TheDaver
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
