<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/core, branch release-1.26.3</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Version bump.</title>
<updated>2025-02-05T16:40:47+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2025-02-05T10:40:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=11b890d66d58efaeaec1f8cd2ddb6227ec5e7798'/>
<id>11b890d66d58efaeaec1f8cd2ddb6227ec5e7798</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Version bump.</title>
<updated>2024-08-12T14:21:52+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2024-08-12T14:21:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ddd5b9c5318d00b17f4d01bb3be1839f39fa6db0'/>
<id>ddd5b9c5318d00b17f4d01bb3be1839f39fa6db0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Optimized chain link usage (ticket #2614).</title>
<updated>2024-05-23T15:15:38+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-05-23T15:15:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=75e3004902586f4120ddac4e3e00802a9024b79e'/>
<id>75e3004902586f4120ddac4e3e00802a9024b79e</id>
<content type='text'>
Previously chain links could sometimes be dropped instead of being reused,
which could result in increased memory consumption during long requests.

A similar chain link issue in ngx_http_gzip_filter_module was fixed in
da46bfc484ef (1.11.10).

Based on a patch by Sangmin Lee.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously chain links could sometimes be dropped instead of being reused,
which could result in increased memory consumption during long requests.

A similar chain link issue in ngx_http_gzip_filter_module was fixed in
da46bfc484ef (1.11.10).

Based on a patch by Sangmin Lee.
</pre>
</div>
</content>
</entry>
<entry>
<title>Version bump.</title>
<updated>2024-05-28T13:14:08+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2024-05-28T13:14:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ee561abfdfebc6de622cf540a49237c745a2e209'/>
<id>ee561abfdfebc6de622cf540a49237c745a2e209</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Stable branch.</title>
<updated>2024-04-23T13:31:41+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-04-23T13:31:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ee19cf9800a08228e335c6775f3fea2c8a6b00e0'/>
<id>ee19cf9800a08228e335c6775f3fea2c8a6b00e0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed undefined behaviour with IPv4-mapped IPv6 addresses.</title>
<updated>2024-03-18T13:14:30+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2024-03-18T13:14:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3d5a356abb4f06b0f103290bd31a4c146233956b'/>
<id>3d5a356abb4f06b0f103290bd31a4c146233956b</id>
<content type='text'>
Previously, it could result when left-shifting signed integer due to implicit
integer promotion, such that the most significant bit appeared on the sign bit.

In practice, though, this results in the same left value as with an explicit
cast, at least on known compilers, such as GCC and Clang.  The reason is that
in_addr_t, which is equivalent to uint32_t and same as "unsigned int" in ILP32
and LP64 data type models, has the same type width as the intermediate after
integer promotion, so there's no side effects such as sign-extension.  This
explains why adding an explicit cast does not change object files in practice.

Found with UndefinedBehaviorSanitizer (shift).

Based on a patch by Piotr Sikora.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, it could result when left-shifting signed integer due to implicit
integer promotion, such that the most significant bit appeared on the sign bit.

In practice, though, this results in the same left value as with an explicit
cast, at least on known compilers, such as GCC and Clang.  The reason is that
in_addr_t, which is equivalent to uint32_t and same as "unsigned int" in ILP32
and LP64 data type models, has the same type width as the intermediate after
integer promotion, so there's no side effects such as sign-extension.  This
explains why adding an explicit cast does not change object files in practice.

Found with UndefinedBehaviorSanitizer (shift).

Based on a patch by Piotr Sikora.
</pre>
</div>
</content>
</entry>
<entry>
<title>Version bump.</title>
<updated>2024-03-21T13:06:21+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-03-21T13:06:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=b1a2b3ebdf336a422ceb94517a0943e28688831d'/>
<id>b1a2b3ebdf336a422ceb94517a0943e28688831d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Version bump.</title>
<updated>2023-10-26T21:29:28+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2023-10-26T21:29:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=1f1bc17ba81eb7eaf0fbadb6bd5fd711f5194d11'/>
<id>1f1bc17ba81eb7eaf0fbadb6bd5fd711f5194d11</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: changed ngx_queue_sort() to use merge sort.</title>
<updated>2023-10-18T01:30:11+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2023-10-18T01:30:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=c93cb45ae30760b7cd4ce2d9e053a36449d4e233'/>
<id>c93cb45ae30760b7cd4ce2d9e053a36449d4e233</id>
<content type='text'>
This improves nginx startup times significantly when using very large number
of locations due to computational complexity of the sorting algorithm being
used: insertion sort is O(n*n) on average, while merge sort is O(n*log(n)).
In particular, in a test configuration with 20k locations total startup
time is reduced from 8 seconds to 0.9 seconds.

Prodded by Yusuke Nojima,
https://mailman.nginx.org/pipermail/nginx-devel/2023-September/NUL3Y2FPPFSHMPTFTL65KXSXNTX3NQMK.html
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This improves nginx startup times significantly when using very large number
of locations due to computational complexity of the sorting algorithm being
used: insertion sort is O(n*n) on average, while merge sort is O(n*log(n)).
In particular, in a test configuration with 20k locations total startup
time is reduced from 8 seconds to 0.9 seconds.

Prodded by Yusuke Nojima,
https://mailman.nginx.org/pipermail/nginx-devel/2023-September/NUL3Y2FPPFSHMPTFTL65KXSXNTX3NQMK.html
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: fixed memory leak on configuration reload with PCRE2.</title>
<updated>2023-10-16T23:39:38+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2023-10-16T23:39:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=284a0c73771e3a2c57af6e74d96d9a6878b2e7b4'/>
<id>284a0c73771e3a2c57af6e74d96d9a6878b2e7b4</id>
<content type='text'>
In ngx_regex_cleanup() allocator wasn't configured when calling
pcre2_compile_context_free() and pcre2_match_data_free(), resulting
in no ngx_free() call and leaked memory.  Fix is ensure that allocator
is configured for global allocations, so that ngx_free() is actually
called to free memory.

Additionally, ngx_regex_compile_context was cleared in
ngx_regex_module_init().  It should be either not cleared, so it will
be freed by ngx_regex_cleanup(), or properly freed.  Fix is to
not clear it, so ngx_regex_cleanup() will be able to free it.

Reported by ZhenZhong Wu,
https://mailman.nginx.org/pipermail/nginx-devel/2023-September/3Z5FIKUDRN2WBSL3JWTZJ7SXDA6YIWPB.html
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In ngx_regex_cleanup() allocator wasn't configured when calling
pcre2_compile_context_free() and pcre2_match_data_free(), resulting
in no ngx_free() call and leaked memory.  Fix is ensure that allocator
is configured for global allocations, so that ngx_free() is actually
called to free memory.

Additionally, ngx_regex_compile_context was cleared in
ngx_regex_module_init().  It should be either not cleared, so it will
be freed by ngx_regex_cleanup(), or properly freed.  Fix is to
not clear it, so ngx_regex_cleanup() will be able to free it.

Reported by ZhenZhong Wu,
https://mailman.nginx.org/pipermail/nginx-devel/2023-September/3Z5FIKUDRN2WBSL3JWTZJ7SXDA6YIWPB.html
</pre>
</div>
</content>
</entry>
</feed>
