Weird crash over night with nginx

[Maxim Dounin]

Hello!

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:

bt

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.:

    worker_rlimit_core 500m;
    working_directory /path/to/corefiles;

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 
configuration.

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.

Maxim Dounin