Hello!

On Thu, Jul 12, 2012 at 05:48:11PM +0100, Russell Howe wrote:

> Earlier this year we noticed a large number of segfaulting nginx processes.
>
> This turned out to be an instance of:
>
> http://forum.nginx.org/read.php?2,213479
>
> whereby we had a config snippet which looked like:
>
> error_page 400 @fallback

Don't do that? (c)

The problem with 400 errors is more or less trivial and the above
link explains it in details. There is no need to debug anything
here, it's mostly about writing code to handle it. (Or probably
about writing code to make the above config invalid and/or provide
a warning.)

Note well that handling of 400 errors isn't really good idea even
with normal uri of an error page, not only with named locations.
As 400 (Bad request) means bad request and you can't really trust
anything got from a client. Unless you really understand what are
you doing and possible implications it's much better idea to let
nginx return builtin error page.

[...]

> Also, I discovered that your nginx-debug RPM doesn't actually include debug symbols (!)
> On CentOS 5 I fixed this by adding to the top of the spec file:
>
> %define __os_install_post \
> /usr/lib/rpm/brp-compress \
> /usr/lib/rpm/brp-strip-static-archive \
> /usr/lib/rpm/brp-strip-comment-note \
>
>
> Which is redefining __os_install_post to be the same as usual, minus the call to /usr/lib/rpm/brp-strip
>
> What was happening was that the nginx binary was built, complete with symbols, copied to nginx.debug, then the original binary was stripped.
>
> Then, __os_install_post ran, which called brp-strip. brp-strip goes and strips all the executables it can find, including nginx.debug!

This looks intresting, thanks. Sergey, could you please take a look?

[...]

Maxim Dounin

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