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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx