Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

BZ-62640: libbtool invocations should use --tag=CC #12

Closed
wants to merge 1 commit into from
Closed

BZ-62640: libbtool invocations should use --tag=CC #12

wants to merge 1 commit into from

Conversation

michael-o
Copy link
Member

When using the generated/provided libtool on a different platform/compiler
libtool complains about the missing tag because a proper configuration for the
current one isn't present and cannot be derived.

Always pass '--tag=CC' for maximum portability. E.g., apr-util and tcnative
require this.

@michael-o
Copy link
Member Author

This requires a backport to 1.6.x and 1.7.x.

@rainerjung
Copy link

  • file build/apr_rules.mk also contains two lines with libtool flags
  • Is it really correct to use the CC tag also for --mode=link? If so, why not in LINK_MODULE?

@michael-o
BZ-62640: libbtool invocations should use --tag=CC
528d95c 
When using the generated/provided libtool on a different platform/compiler
libtool complains about the missing tag because a proper configuration for the
current one isn't present and cannot be derived.

Always pass '--tag=CC' for maximum portability. E.g., apr-util and tcnative
require this.
@michael-o
Copy link
Member Author

file build/apr_rules.mk also contains two lines with libtool flags

You obviously mean these:
https://github.com/apache/apr/blob/trunk/build/apr_rules.mk.in#L82-L83

While one coould pass them here from outside, most people know little about libtool. It took me some time to solve this puzzle. I don't want anyone else to trip about this. It should just work. Maybe you are aware of a better example.

Is it really correct to use the CC tag also for --mode=link?

As far as I understood the documentation -- yes. We are requesting libtool to link C objects with CC (the compiler). See here.

If so, why not in LINK_MODULE?

Very well spotted. I missed this one out. Pushed an update.

If you know a better approach, I am all years. This will solve a linkage issue with tcnative also.

@wrowe
Copy link
Member

wrowe commented Aug 30, 2018

I'm confused by the docs link you provided;

"If it can’t infer a tag, then it defaults to the configuration for the C language."

So, --tag=CC is default behavior already. I'm puzzled precisely what problem this solves?

@michael-o
Copy link
Member Author

michael-o commented Sep 23, 2018 •
edited
Loading

@wrowe This is only valid for the same system and compiler. It does not work as soon as you move to a different OS/compiler. This is true for my case. I am on HP-UX with aCC. Without that, the Makefile is just unusalble and not really portable. The available_tags in libtool are simply empty when generated on my machine, thus unusable.

I consider this as a no-op change for non-affected users, but as a huge improvement for other OSes.

@michael-o
Copy link
Member Author

@rainerjung Can we reconsider this?

@minfrin
Copy link
Contributor

minfrin commented Aug 17, 2019

Committed revision 1865343.

@michael-o
Copy link
Member Author

Closing, it is in trunk. Will open new PRs for 1.7.x and 1.6.x.

@michael-o michael-o closed this Aug 18, 2019
@michael-o michael-o deleted the BZ-62640 branch August 19, 2019 08:27
asfgit pushed a commit that referenced this pull request Dec 16, 2020
@ylavic
Merge r1883750 from trunk:
2b85c17 
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
@ylavic
apr_pools: lock parent pool in pool_destroy_debug().
94d2e04 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@michael-o @rainerjung @wrowe @minfrin