Weird crash over night with nginx
mdounin at mdounin.ru
Mon Mar 22 19:00:02 MSK 2010
On Mon, Mar 22, 2010 at 04:14:33PM +0100, Robert Gabriel wrote:
> And how am I suppose to do the backtrace, I mean I cant reproduce the
> error or you just need a simple backtrace?
You have to configure your system to dump cores, and once you'll
have coredump run
gdb /path/to/nginx /path/to/nginx.core
then in gdb:
Depending on your OS procedure to enable core dumps is different,
but it may be simplified using nginx's own global direcitives
worker_rlimit_core and working_directory, e.g.:
nginx must have write access to '/path/to/corefiles' directory.
Note well: it's good idea to make sure your nginx binary isn't
stripped (e.g. via file(1) command).
If you are unable to reproduce segmentation fault and therefore
unable to obtain coredump - it's still good idea to provide nginx
-V output and your config. There is a chance that segmentation
fault you've seen was already fixed or caused by known bad
In nginx 0.8.34 I'm currently aware of at least 4 possible
segfaults: 2 caused by bugs (in fastcgi stderr handling and in
subrequest loop handling; patches are available) and 2 caused by
known bad configurations (error_page 400 redirected to named
location, "if" usage as outlined in IfIsEvil wiki page). Not even
talking about older versions.
More information about the nginx