On Windows, a worker process does not call ngx_slab_init() from ngx_init_zone_pool(), so ngx_slab_max_size, ngx_slab_exact_size, and ngx_slab_exact_shift were left uninitialized.
This also fixes potential undefined behaviour in the range and slice filter modules, caused by local overflows of signed integers in expressions.
The error is fatal when configuring a new socket, so the ", ignored" part is not appropriate and was removed.
When closing a socket with SO_REUSEPORT, Linux drops all connections waiting in this socket's listen queue. Previously, it was believed to only result in connection resets when reconfiguring nginx to use smaller number of worker processes. It also results in connection resets during configuration testing though. Workaround is to avoid using SO_REUSEPORT when testing configuration. It should prevent listening sockets from being created if a conflicting socket already exists, while still preserving detection of other possible errors. It should also cover UDP sockets. The only downside of this approach seems to be that a configuration testing won't be able to properly report the case when nginx was compiled with SO_REUSEPORT, but the kernel is not able to set it. Such errors will be reported on a real start instead.
It is safe because re-sending still works during graceful shutdown as long as resolving takes place (and resolve tasks set their own timeouts that are not cancelable). Also, the new ctx->cancelable flag can be set to make resolve task's timeout event cancelable.
No functional changes.
Notably, on ppc64 with 64k pagesize, slab 0 (of size 8) requires 128 64-bit elements for bitmasks. The code bogusly assumed that one uintptr_t is enough for bitmasks plus at least one free slot.
Resolving an SRV record includes resolving its host names in subrequests. Previously, if memory allocation failed while reporting a subrequest result after receiving a response from a DNS server, the SRV resolve handler was called immediately with the NGX_ERROR state. However, if the SRV record included another copy of the resolved name, it was reported once again. This could trigger the use-after-free memory access after SRV resolve handler freed the resolve context by calling ngx_resolve_name_done(). Now the SRV resolve handler is called only when all its subrequests are completed.