build/apr_common.m4: avoid explicit inclusion of '"confdefs.h"' #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
FYI, configure has always inlined the contents of confdefs.h at the top of each test program generated by AC_LANG_SOURCE / AC_LANG_PROGRAM, at least as far back as 2.50. It should never be necessary to refer to confdefs.h directly. I am still investigating why this is a new failure in 2.69d. |
asfgit
pushed a commit
that referenced
this pull request
Dec 16, 2020
apr_pools: lock parent pool in pool_destroy_debug().
By using apr_pool_clear_debug() instead of pool_clear_debug() in
pool_destroy_debug() we gain the locking provided by the former and thus
protection from concurrent access from apr_pool_walk_tree(), which is
undefined behaviour.
While pool_destroy_debug()=>apr_pool_clear_debug()=>pool_clear_debug() calls
pool_destroy_debug() for all the children pools, this does not cause a deadlock
because apr_pool_clear_debug() locks the parent pool only (not the pool itself)
and thus pool_destroy_debug(pool->child) locks the current pool with no issue.
This fixes use-after-free like the below in httpd (with -D APR_POOL_DEBUG):
=================================================================
==2026856==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600025acf0 at pc 0x7fe738f4c5be bp 0x7fe718598110 sp 0x7fe718598108
READ of size 8 at 0x60600025acf0 thread T51
#0 0x7fe738f4c5bd in apr_thread_mutex_lock locks/unix/thread_mutex.c:124
#1 0x7fe738f4e01c in apr_pool_walk_tree memory/unix/apr_pools.c:1505
#2 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
#3 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
#4 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
#5 0x7fe738f5027c in apr_pool_find memory/unix/apr_pools.c:2291
#6 0x7fe738f14aba in apr_table_mergen tables/apr_tables.c:746
#7 0x5578ad926a25 in ap_set_keepalive /home/ylavic/src/apache/httpd/trunk/modules/http/http_protocol.c:309
#8 0x5578ad93933f in ap_http_header_filter /home/ylavic/src/apache/httpd/trunk/modules/http/http_filters.c:1376
#9 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#10 0x5578ad9a67f3 in ap_content_length_filter /home/ylavic/src/apache/httpd/trunk/server/protocol.c:2046
#11 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#12 0x5578ad9405ae in ap_byterange_filter /home/ylavic/src/apache/httpd/trunk/modules/http/byterange_filter.c:463
#13 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#14 0x7fe7330e398b in ap_headers_output_filter /home/ylavic/src/apache/httpd/trunk/modules/metadata/mod_headers.c:891
#15 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#16 0x7fe732e32dba in session_output_filter /home/ylavic/src/apache/httpd/trunk/modules/session/mod_session.c:501
#17 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#18 0x5578ad9c8ee5 in default_handler /home/ylavic/src/apache/httpd/trunk/server/core.c:5188
#19 0x5578ad9431bb in ap_run_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:170
#20 0x5578ad944941 in ap_invoke_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:444
#21 0x5578ad92cc23 in ap_process_async_request /home/ylavic/src/apache/httpd/trunk/modules/http/http_request.c:463
#22 0x5578ad924d7c in ap_process_http_async_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:158
#23 0x5578ad925410 in ap_process_http_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:252
#24 0x5578ad97e04d in ap_run_process_connection /home/ylavic/src/apache/httpd/trunk/server/connection.c:42
#25 0x7fe735c7ef79 in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1097
#26 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
#27 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
#28 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477
#29 0x7fe738d6ed4e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfdd4e)
0x60600025acf0 is located 48 bytes inside of 64-byte region [0x60600025acc0,0x60600025ad00)
freed by thread T63 here:
#0 0x7fe7391ed277 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
#1 0x7fe738f4e9e5 in pool_clear_debug memory/unix/apr_pools.c:1893
#2 0x7fe738f4ecb2 in pool_destroy_debug memory/unix/apr_pools.c:1956
#3 0x7fe738f4eeeb in apr_pool_destroy_debug memory/unix/apr_pools.c:2002
#4 0x5578ada2534b in ap_queue_info_push_pool /home/ylavic/src/apache/httpd/trunk/server/mpm_fdqueue.c:230
#5 0x7fe735c81412 in process_lingering_close /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1686
#6 0x7fe735c7f9bc in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1255
#7 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
#8 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
#9 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/branches/1.7.x@1883751 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Dec 16, 2020
By using apr_pool_clear_debug() instead of pool_clear_debug() in
pool_destroy_debug() we gain the locking provided by the former and thus
protection from concurrent access from apr_pool_walk_tree(), which is
undefined behaviour.
While pool_destroy_debug()=>apr_pool_clear_debug()=>pool_clear_debug() calls
pool_destroy_debug() for all the children pools, this does not cause a deadlock
because apr_pool_clear_debug() locks the parent pool only (not the pool itself)
and thus pool_destroy_debug(pool->child) locks the current pool with no issue.
This fixes use-after-free like the below in httpd (with -D APR_POOL_DEBUG):
=================================================================
==2026856==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600025acf0 at pc 0x7fe738f4c5be bp 0x7fe718598110 sp 0x7fe718598108
READ of size 8 at 0x60600025acf0 thread T51
#0 0x7fe738f4c5bd in apr_thread_mutex_lock locks/unix/thread_mutex.c:124
#1 0x7fe738f4e01c in apr_pool_walk_tree memory/unix/apr_pools.c:1505
#2 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
#3 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
#4 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
#5 0x7fe738f5027c in apr_pool_find memory/unix/apr_pools.c:2291
#6 0x7fe738f14aba in apr_table_mergen tables/apr_tables.c:746
#7 0x5578ad926a25 in ap_set_keepalive /home/ylavic/src/apache/httpd/trunk/modules/http/http_protocol.c:309
#8 0x5578ad93933f in ap_http_header_filter /home/ylavic/src/apache/httpd/trunk/modules/http/http_filters.c:1376
#9 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#10 0x5578ad9a67f3 in ap_content_length_filter /home/ylavic/src/apache/httpd/trunk/server/protocol.c:2046
#11 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#12 0x5578ad9405ae in ap_byterange_filter /home/ylavic/src/apache/httpd/trunk/modules/http/byterange_filter.c:463
#13 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#14 0x7fe7330e398b in ap_headers_output_filter /home/ylavic/src/apache/httpd/trunk/modules/metadata/mod_headers.c:891
#15 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#16 0x7fe732e32dba in session_output_filter /home/ylavic/src/apache/httpd/trunk/modules/session/mod_session.c:501
#17 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
#18 0x5578ad9c8ee5 in default_handler /home/ylavic/src/apache/httpd/trunk/server/core.c:5188
#19 0x5578ad9431bb in ap_run_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:170
#20 0x5578ad944941 in ap_invoke_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:444
#21 0x5578ad92cc23 in ap_process_async_request /home/ylavic/src/apache/httpd/trunk/modules/http/http_request.c:463
#22 0x5578ad924d7c in ap_process_http_async_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:158
#23 0x5578ad925410 in ap_process_http_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:252
#24 0x5578ad97e04d in ap_run_process_connection /home/ylavic/src/apache/httpd/trunk/server/connection.c:42
#25 0x7fe735c7ef79 in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1097
#26 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
#27 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
#28 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477
#29 0x7fe738d6ed4e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfdd4e)
0x60600025acf0 is located 48 bytes inside of 64-byte region [0x60600025acc0,0x60600025ad00)
freed by thread T63 here:
#0 0x7fe7391ed277 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
#1 0x7fe738f4e9e5 in pool_clear_debug memory/unix/apr_pools.c:1893
#2 0x7fe738f4ecb2 in pool_destroy_debug memory/unix/apr_pools.c:1956
#3 0x7fe738f4eeeb in apr_pool_destroy_debug memory/unix/apr_pools.c:2002
#4 0x5578ada2534b in ap_queue_info_push_pool /home/ylavic/src/apache/httpd/trunk/server/mpm_fdqueue.c:230
#5 0x7fe735c81412 in process_lingering_close /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1686
#6 0x7fe735c7f9bc in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1255
#7 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
#8 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
#9 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1883750 13f79535-47bb-0310-9956-ffa450edef68
The failure is observed on `autoconf-2.69d` (soon to be released
as `autoconf-2.70`). There `int64_t` detection fails as:
```
$ autoreconf && ./configure
...
checking whether int64_t and int use fmt %d... no
checking whether int64_t and long use fmt %ld... no
checking whether int64_t and long long use fmt %lld... no
configure: error: could not determine the string function for int64_t
```
This happens because `./configure` always stumbles on warning:
```
configure:3350: gcc -c -g -O2 -Werror conftest.c >&5
In file included from conftest.c:31:
confdefs.h:22: error: "__STDC_WANT_IEC_60559_ATTRIBS_EXT__" redefined [-Werror]
22 | #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
|
```
It's triggered by double inclusion of `"confdefs.h"` contents:
explicitly in `APR_TRY_COMPILE_NO_WARNING` macro and implicitly
via `AC_LANG_SOURCE` use.
To fix it and avoid having to define `main()` declaration the change
uses `AC_LANG_PROGRAM` instead.
Tested on both `autoconf-2.69` and `autoconf-2.69d`.
Bug: https://bugs.gentoo.org/738156
Bug: https://bugs.gentoo.org/750353
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
Thanks, merged in APR's repository (https://svn.apache.org/r1887279) |
asfgit
pushed a commit
that referenced
this pull request
Mar 11, 2021
build/apr_common.m4: avoid explicit inclusion of "confdefs.h"
The failure is observed on `autoconf-2.69d` (soon to be released
as `autoconf-2.70`). There `int64_t` detection fails as:
$ autoreconf && ./configure
checking whether int64_t and int use fmt %d... no
checking whether int64_t and long use fmt %ld... no
checking whether int64_t and long long use fmt %lld... no
configure: error: could not determine the string function for int64_t
```
This happens because `./configure` always stumbles on warning:
configure:3350: gcc -c -g -O2 -Werror conftest.c >&5
In file included from conftest.c:31:
confdefs.h:22: error: "__STDC_WANT_IEC_60559_ATTRIBS_EXT__" redefined [-Werror]
22 | #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
|
It's triggered by double inclusion of `"confdefs.h"` contents:
explicitly in `APR_TRY_COMPILE_NO_WARNING` macro and implicitly
via `AC_LANG_SOURCE` use.
To fix it and avoid having to define `main()` declaration the change
uses `AC_LANG_PROGRAM` instead.
Tested on both `autoconf-2.69` and `autoconf-2.69d`.
Github: closes #25
Submitted by: Sergei Trofimovich <slyfox gentoo.org>
Reviewed by: ylavic
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/branches/1.7.x@1887485 13f79535-47bb-0310-9956-ffa450edef68
notroj
added a commit
to notroj/apr
that referenced
this pull request
Mar 23, 2021
(possibly fallout from r1887279 / pull apache#25 ??)
notroj
added a commit
to notroj/apr
that referenced
this pull request
Mar 24, 2021
(possibly fallout from r1887279 / pull apache#25 ??)
asfgit
pushed a commit
that referenced
this pull request
Mar 24, 2021
AC_LANG_PROGRAM generates an "int main()" prototype which some compilers warn about. Restore AC_LANG_SOURCE to manually set the correct main() but do not #include "confdefs.h" if it is inlined already by AC_LANG_SOURCE (i.e. check whether PACKAGE_NAME is already defined). Github: closes #25 git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1888017 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Mar 24, 2021
Follow up to r1887279: fix new APR_TRY_COMPILE_NO_WARNING. AC_LANG_PROGRAM generates an "int main()" prototype which some compilers warn about. Restore AC_LANG_SOURCE to manually set the correct main() but do not #include "confdefs.h" if it is inlined already by AC_LANG_SOURCE (i.e. check whether PACKAGE_NAME is already defined). Github: closes #25 git-svn-id: https://svn.apache.org/repos/asf/apr/apr/branches/1.7.x@1888018 13f79535-47bb-0310-9956-ffa450edef68
djain8
pushed a commit
to djain8/apr
that referenced
this pull request
Jun 26, 2023
The failure is observed on `autoconf-2.69d` (soon to be released
as `autoconf-2.70`). There `int64_t` detection fails as:
$ autoreconf && ./configure
checking whether int64_t and int use fmt %d... no
checking whether int64_t and long use fmt %ld... no
checking whether int64_t and long long use fmt %lld... no
configure: error: could not determine the string function for int64_t
```
This happens because `./configure` always stumbles on warning:
configure:3350: gcc -c -g -O2 -Werror conftest.c >&5
In file included from conftest.c:31:
confdefs.h:22: error: "__STDC_WANT_IEC_60559_ATTRIBS_EXT__" redefined [-Werror]
22 | #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
|
It's triggered by double inclusion of `"confdefs.h"` contents:
explicitly in `APR_TRY_COMPILE_NO_WARNING` macro and implicitly
via `AC_LANG_SOURCE` use.
To fix it and avoid having to define `main()` declaration the change
uses `AC_LANG_PROGRAM` instead.
Tested on both `autoconf-2.69` and `autoconf-2.69d`.
Github: closes apache#25
Submitted by: Sergei Trofimovich <slyfox gentoo.org>
Reviewed by: ylavic
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1887279 13f79535-47bb-0310-9956-ffa450edef68
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The failure is observed on
autoconf-2.69d(soon to be releasedas
autoconf-2.70). Thereint64_tdetection fails as:This happens because
./configurealways stumbles on warning:It's triggered by double inclusion of
"confdefs.h"contents:explicitly in
APR_TRY_COMPILE_NO_WARNINGmacro and implicitlyvia
AC_LANG_SOURCEuse.To fix it and avoid having to define
main()declaration the changeuses
AC_LANG_PROGRAMinstead.Tested on both
autoconf-2.69andautoconf-2.69d.Bug: https://bugs.gentoo.org/738156
Bug: https://bugs.gentoo.org/750353