-
Notifications
You must be signed in to change notification settings - Fork 207
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.
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
Added switch_thread_getname and switch_thread_setname functions #4
base: trunk
Are you sure you want to change the base?
Conversation
a known (and therfore handable) issue git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561040 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561209 13f79535-47bb-0310-9956-ffa450edef68
PR 55928. [Jozef Hatala <jh-asf skrt org>] git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561260 13f79535-47bb-0310-9956-ffa450edef68
the pathlength, which is much less than 255. So use the method from posix sems, which we've used for years! git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561265 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561321 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561347 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561356 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561361 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561384 13f79535-47bb-0310-9956-ffa450edef68
so we can fix it without breaking it. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561394 13f79535-47bb-0310-9956-ffa450edef68
FIX data corruption git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1561555 13f79535-47bb-0310-9956-ffa450edef68
Introduce non-exported sys/attr.h autoconf flag for OS/X git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1567722 13f79535-47bb-0310-9956-ffa450edef68
…lete patch git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1567758 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1571894 13f79535-47bb-0310-9956-ffa450edef68
…ents git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1575340 13f79535-47bb-0310-9956-ffa450edef68
http://git.savannah.gnu.org/cgit/config.git. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1575509 13f79535-47bb-0310-9956-ffa450edef68
for gen_test_char when using an old libtool. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1578420 13f79535-47bb-0310-9956-ffa450edef68
apr_sockaddr_t into a specified pool. Submitted by: Yann Ylavic <ylavic.dev gmail.com> Reviewed by: trawick git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1587045 13f79535-47bb-0310-9956-ffa450edef68
process pthread mutexes. Submitted by: Yann Ylavic <ylavic.dev gmail.com> Reviewed by: trawick git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1587063 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1587066 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Yann Ylavic <ylavic.dev gmail.com> Reviewed by: trawick git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1587543 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1587545 13f79535-47bb-0310-9956-ffa450edef68
as described by RFC4514 and RFC4515 respectively. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1588878 13f79535-47bb-0310-9956-ffa450edef68
… filter escaping, allowing the option to escape both at the same time. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1588937 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1589982 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1590624 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1590663 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1593611 13f79535-47bb-0310-9956-ffa450edef68
Enabled by new configure option --enable-pool-concurrency-check. Compared to pool-owner-debugging, this only detects cases where there is actual contention between accesses. The advantage is that runtime costs should be relatively low. The diagnostic messages could still use some improvement. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1593614 13f79535-47bb-0310-9956-ffa450edef68
Add new --enable-allocator-guard-pages configure option which works like --enable-allocator-uses-mmap, but will also add inaccessible guard pages before and after each memnode. This will result in higher ressource usage but allow to find/protect against certain buffer overflow/overread bugs. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1593615 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1770471 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1770489 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1770832 13f79535-47bb-0310-9956-ffa450edef68
…e pool given to crypto_key()/crypto_passphrase(). git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1772414 13f79535-47bb-0310-9956-ffa450edef68
Patch by Hanno Böck git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1772803 13f79535-47bb-0310-9956-ffa450edef68
…ogic git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1773849 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1773852 13f79535-47bb-0310-9956-ffa450edef68
…on time. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1773929 13f79535-47bb-0310-9956-ffa450edef68
…nymore git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774348 13f79535-47bb-0310-9956-ffa450edef68
* file_io/win32/filestat.c (apr_file_info_get): Use GetFileSizeEx() instead of GetFileInformationByHandleEx() when only APR_FINFO_SIZE is requested. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774712 13f79535-47bb-0310-9956-ffa450edef68
webviewer:projectlanguage properties for TortoiseSVN. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774713 13f79535-47bb-0310-9956-ffa450edef68
commonly used file types. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774714 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774715 13f79535-47bb-0310-9956-ffa450edef68
* mmap/win32/mmap.c (apr_mmap_create): Use CreateFileMappingW() if APR_HAS_UNICODE_FS and IF_WIN_OS_IS_UNICODE. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774923 13f79535-47bb-0310-9956-ffa450edef68
As noticed by rjung, not all pthread implementations have mutex_timedlock(), like Solaris 8, so proc_mutex_proc_pthread_timedacquire() can return APR_ENOTIMPL. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774973 13f79535-47bb-0310-9956-ffa450edef68
Wrong place for this check, and wrong value too (should be 1 << 17). But actually the max is already caped by _crypt_gensalt_blowfish_rn() which is necessarily called previously in apr_bcrypt_encode(). git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774976 13f79535-47bb-0310-9956-ffa450edef68
the second/double proc_ (consistently with other mechanisms). git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1775069 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1776994 13f79535-47bb-0310-9956-ffa450edef68
http://git.savannah.gnu.org/cgit/config.git. git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1776998 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1778149 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Michal Karm Babacek <karm fedoraproject.org> Reviewed by: ylavic git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1778153 13f79535-47bb-0310-9956-ffa450edef68
00e195a
to
b576e50
Compare
b576e50
to
3205631
Compare
|
||
APR_DECLARE(apr_status_t) apr_thread_setname(apr_thread_t *thread, const char *name) | ||
{ | ||
return APR_ENOTIMPL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @jeking3
I not have windows PC and cannot build and test code for Windows platform. Could you create PR to my repo? I will merge your PR into this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend committing this because technically it isn't wrong - it returns "not implemented", and someone will do then win32 side when they need it. I would implement it such that the documented API would be used, and then if Windows is an earlier version than that API supports, to use the trick found in https://www.codeproject.com/articles/8549/name-your-threads-in-the-vc-debugger-thread-list.
If pull requests here leveraged Travis CI and Appveyor you would be able to make those changes and see the tests pass... it's too bad the project doesn't leverage the free CI tools that exist for open source projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeking3, could you mark PR as reviewed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, although I should ask why folks more closely tied to the project are not reviewing the pull requests? I am a PMC member on Thrift, and I maintain some Boost libraries... I don't look at apr that often.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeking3: activity mostly happens on the [email protected] mailing list and bugzilla.
PRs are looked at from time to time, by individuals...
@sergey-safarov: a new function mostly ENOTIMPL (but on some pthread implementations, as _np suffix suggests) is not very attractive for APR (P stands for Portable). Any chance to at least handle Windows per MSDN link? (I can't compile nor test myself unfortunately).
Maybe for your use case apr_os_thread_get() could help to do native calls on the native thread descriptor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend adding another story to the backlog to get Win32 thread naming to work per the comments here.
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
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
This can happen in cprng_stream_ctx_make() on error paths, or at thread exit with APR_CRYPTO_PRNG_PER_THREAD like the below. Direct leak of 64 byte(s) in 8 object(s) allocated from: #0 0x7efd954c7628 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628) #1 0x7efd921db6ca (<unknown module>) #2 0x7efd952937a2 in apr_crypto_prng_create crypto/apr_crypto_prng.c:367 #3 0x7efd95292c1e in apr_crypto_random_thread_bytes crypto/apr_crypto_prng.c:218 #4 0x5611dbbb9440 in thread_func /home/yle/src/apache/apr/trunk.ro/test/testcrypto.c:2597 #5 0x7efd9537dd86 in dummy_worker threadproc/unix/thread.c:148 #6 0x7efd951efea6 in start_thread nptl/pthread_create.c:477 git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1893201 13f79535-47bb-0310-9956-ffa450edef68
No description provided.