[jira] [Commented] (PROTON-2462) Incorrect error message in stream receiver message for AMQP value bodies not readable
[ https://issues.apache.org/jira/browse/PROTON-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440668#comment-17440668 ] ASF subversion and git services commented on PROTON-2462: - Commit b33e4e592cb4dc36f889e5de269676928be3ef69 in qpid-protonj2's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=qpid-protonj2.git;h=b33e4e5 ] PROTON-2462 Fix error message for stream receiver AmqpValue body types > Incorrect error message in stream receiver message for AMQP value bodies not > readable > -- > > Key: PROTON-2462 > URL: https://issues.apache.org/jira/browse/PROTON-2462 > Project: Qpid Proton > Issue Type: Bug > Components: protonj2 >Affects Versions: protonj2-1.0.0-M3 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: protonj2-1.0.0-M4 > > > The error message used when a stream receiver encounters an AMQP value body > in the incoming message is incorrect. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2462) Incorrect error message in stream receiver message for AMQP value bodies not readable
[ https://issues.apache.org/jira/browse/PROTON-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved PROTON-2462. - Resolution: Fixed > Incorrect error message in stream receiver message for AMQP value bodies not > readable > -- > > Key: PROTON-2462 > URL: https://issues.apache.org/jira/browse/PROTON-2462 > Project: Qpid Proton > Issue Type: Bug > Components: protonj2 >Affects Versions: protonj2-1.0.0-M3 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: protonj2-1.0.0-M4 > > > The error message used when a stream receiver encounters an AMQP value body > in the incoming message is incorrect. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2462) Incorrect error message in stream receiver message for AMQP value bodies not readable
Timothy A. Bish created PROTON-2462: --- Summary: Incorrect error message in stream receiver message for AMQP value bodies not readable Key: PROTON-2462 URL: https://issues.apache.org/jira/browse/PROTON-2462 Project: Qpid Proton Issue Type: Bug Components: protonj2 Affects Versions: protonj2-1.0.0-M3 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: protonj2-1.0.0-M4 The error message used when a stream receiver encounters an AMQP value body in the incoming message is incorrect. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2206) ASAN use-after-free of qdr_link_t by I/O thread
[
https://issues.apache.org/jira/browse/DISPATCH-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440574#comment-17440574
]
Jiri Daněk commented on DISPATCH-2206:
--
And, the results are in!
https://github.com/jiridanek/qpid-dispatch/runs/4141119600?check_suite_focus=true#step:9:446
{noformat}
27: ==4101==ERROR: AddressSanitizer: heap-use-after-free on address
0x617000986b30 at pc 0x56236ce30ef2 bp 0x7ff4dcfddc00 sp 0x7ff4dcfddbf0
27: READ of size 8 at 0x617000986b30 thread T2
27: #0 0x56236ce30ef1 in qdr_link_get_context
../src/router_core/connections.c:516
27: #1 0x56236cf5d601 in CORE_link_second_attach ../src/router_node.c:1736
27: #2 0x56236ce2c0d1 in qdr_connection_process
../src/router_core/connections.c:355
27: #3 0x56236cf53035 in AMQP_writable_conn_handler ../src/router_node.c:299
27: #4 0x56236cd5e201 in writable_handler ../src/container.c:388
27: #5 0x56236cd6317f in qd_container_handle_event ../src/container.c:744
27: #6 0x56236cf75ab5 in handle ../src/server.c:1108
27: #7 0x56236cf75cd2 in thread_run ../src/server.c:1133
27: #8 0x56236cdef964 in _thread_init ../src/posix/threading.c:172
27: #9 0x7ff4e4dd5608 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
27: #10 0x7ff4e3fcb292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
27:
27: 0x617000986b30 is located 176 bytes inside of 704-byte region
[0x617000986a80,0x617000986d40)
27: freed by thread T1 here:
27: #0 0x7ff4e53937cf in __interceptor_free
(/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
27: #1 0x56236cd30b84 in qd_dealloc ../src/alloc_pool.c:497
27: #2 0x56236ceb68e3 in free_qdr_link_t ../src/router_core/router_core.c:35
27: #3 0x56236ce3cc11 in qdr_link_cleanup_CT
../src/router_core/connections.c:1121
27: #4 0x56236ce50a5f in qdr_link_processing_complete_CT
../src/router_core/connections.c:2220
27: #5 0x56236cedcec7 in router_core_thread
../src/router_core/router_core_thread.c:236
27: #6 0x56236cdef964 in _thread_init ../src/posix/threading.c:172
27: #7 0x7ff4e4dd5608 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
27:
27: previously allocated by thread T2 here:
27: #0 0x7ff4e5394aa5 in posix_memalign
(/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5)
27: #1 0x56236cd2c9cd in qd_alloc ../src/alloc_pool.c:393
27: #2 0x56236ceb68ab in new_qdr_link_t ../src/router_core/router_core.c:35
27: #3 0x56236ce31b29 in qdr_link_first_attach
../src/router_core/connections.c:617
27: #4 0x56236cf56125 in AMQP_outgoing_link_handler
../src/router_node.c:1025
27: #5 0x56236cd5b620 in setup_outgoing_link ../src/container.c:157
27: #6 0x56236cd61ccc in qd_container_handle_event ../src/container.c:659
27: #7 0x56236cf75ab5 in handle ../src/server.c:1108
27: #8 0x56236cf75cd2 in thread_run ../src/server.c:1133
27: #9 0x56236cdef964 in _thread_init ../src/posix/threading.c:172
27: #10 0x7ff4e4dd5608 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
27:
27: Thread T2 created by T0 here:
27: #0 0x7ff4e52c0805 in pthread_create
(/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
27: #1 0x56236cdefad3 in sys_thread ../src/posix/threading.c:181
27: #2 0x56236cf7d758 in qd_server_run ../src/server.c:1525
27: #3 0x56236cfd8791 in main_process ../router/src/main.c:115
27: #4 0x56236cfda795 in main ../router/src/main.c:369
27: #5 0x7ff4e3ed00b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
27:
27: Thread T1 created by T0 here:
27: #0 0x7ff4e52c0805 in pthread_create
(/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
27: #1 0x56236cdefad3 in sys_thread ../src/posix/threading.c:181
27: #2 0x56236ceb8817 in qdr_core ../src/router_core/router_core.c:124
27: #3 0x56236cf5ec5c in qd_router_setup_late ../src/router_node.c:2127
27: #4 0x7ff4dfe06ff4 (/lib/x86_64-linux-gnu/libffi.so.7+0x6ff4)
27: #5 0x7ffdb8b9975f ([stack]+0x2175f)
27:
27: SUMMARY: AddressSanitizer: heap-use-after-free
../src/router_core/connections.c:516 in qdr_link_get_context
27: Shadow bytes around the buggy address:
27: 0x0c2e80128d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
27: 0x0c2e80128d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
27: 0x0c2e80128d30: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
27: 0x0c2e80128d40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
27: 0x0c2e80128d50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
27: =>0x0c2e80128d60: fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd
27: 0x0c2e80128d70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
27: 0x0c2e80128d80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
27: 0x0c2e80128d90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
27: 0x0c2e80128da0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
27: 0x0c2e80128db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
27: S
[jira] [Commented] (DISPATCH-2206) ASAN use-after-free of qdr_link_t by I/O thread
[
https://issues.apache.org/jira/browse/DISPATCH-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440541#comment-17440541
]
Jiri Daněk commented on DISPATCH-2206:
--
[~gmurthy] I can try. My procedure is to take this PR [1] which sets memory
pool max size to 0, cherry-pick that onto the branch, and run the test in a
loop. It always fails at tests 9 and 63 (or 64?) because these check something
specific about the memory pools. Thankfully, this is test 27, so it should
hopefully work here.
[1]
https://github.com/apache/qpid-dispatch/pull/1419/commits/f72028364282d7e1d88f3a05dab35dda76265b6d
> ASAN use-after-free of qdr_link_t by I/O thread
> ---
>
> Key: DISPATCH-2206
> URL: https://issues.apache.org/jira/browse/DISPATCH-2206
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.16.1
>Reporter: Ken Giusti
>Priority: Major
> Labels: asan
> Fix For: 1.19.0
>
>
> [https://github.com/apache/qpid-dispatch/blob/main/src/router_core/connections.c#L1344]
>
> {{27: ==3859==ERROR: AddressSanitizer: use-after-poison on address
> 0x61700017e030 at pc 0x56212343cdac bp 0x7f9d33c40c90 sp 0x7f9d33c40c80 }}
> {{ }}{{}}
> 27: READ of size 8 at 0x61700017e030 thread T2
> {{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{ }}{{}}
> 27: #0 0x56212343cdab in qdr_link_get_context
> ../src/router_core/connections.c:498
> {{}}{{ }}{{}}
> 27: #1 0x56212352ec25 in CORE_link_second_attach ../src/router_node.c:1729
> {{}}{{ }}{{}}
> 27: #2 0x5621234388df in qdr_connection_process
> ../src/router_core/connections.c:355
> {{}}{{ }}{{}}
> 27: #3 0x56212338eccf in writable_handler ../src/container.c:396
> {{}}{{ }}{{}}
> 27: #4 0x56212338eccf in qd_container_handle_event ../src/container.c:748
> {{}}{{ }}{{}}
> 27: #5 0x562123547289 in handle ../src/server.c:1108
> {{}}{{ }}{{}}
> 27: #6 0x562123554c9f in thread_run ../src/server.c:1133
> {{}}{{ }}{{}}
> 27: #7 0x7f9d3ba6c608 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> {{}}{{ }}{{}}
> 27: #8 0x7f9d3ac33292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: 0x61700017e030 is located 176 bytes inside of 704-byte region
> [0x61700017df80,0x61700017e240)
> {{}}{{ }}{{}}
> 27: allocated by thread T2 here:
> {{}}{{ }}{{}}
> 27: #0 0x7f9d3bfd9aa5 in posix_memalign
> (/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5)
> {{}}{{ }}{{}}
> 27: #1 0x5621233247b0 in qd_alloc ../src/alloc_pool.c:396
> {{}}{{ }}{{}}
> 27: #2 0x56212343d4c9 in qdr_link_first_attach
> ../src/router_core/connections.c:592
> {{}}{{ }}{{}}
> 27: #3 0x56212352dde9 in AMQP_outgoing_link_handler
> ../src/router_node.c:1018
> {{}}{{ }}{{}}
> 27: #4 0x562123547289 in handle ../src/server.c:1108
> {{}}{{ }}{{}}
> 27: #5 0x562123554c9f in thread_run ../src/server.c:1133
> {{}}{{ }}{{}}
> 27: #6 0x7f9d3ba6c608 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: Thread T2 created by T0 here:
> {{}}{{ }}{{}}
> 27: #0 0x7f9d3bf05805 in pthread_create
> (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
> {{}}{{ }}{{}}
> 27: #1 0x562123403bcf in sys_thread ../src/posix/threading.c:181
> {{}}{{ }}{{}}
> 27: #2 0x56212355541e in qd_server_run ../src/server.c:1522
> {{}}{{ }}{{}}
> 27: #3 0x56212359f46c in main_process ../router/src/main.c:115
> {{}}{{ }}{{}}
> 27: #4 0x56212329bc50 in main ../router/src/main.c:369
> {{}}{{ }}{{}}
> 27: #5 0x7f9d3ab380b2 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: SUMMARY: AddressSanitizer: use-after-poison
> ../src/router_core/connections.c:498 in qdr_link_get_context
> {{}}{{ }}{{}}
> 27: Shadow bytes around the buggy address:
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bb0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bc0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bd0: f7 f7 f7 f7 f7 f7 f7 00 fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> {{}}{{ }}{{}}
> 27: =>0x0c2e80027c00: 00 00 f7 f7 f7 f7[f7]f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c10: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c20: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c30: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c40: f7 f7 f7 f7 f7 f7 f7 00 fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
[GitHub] [qpid-dispatch] jiridanek commented on a change in pull request #1419: NO MERGE, Trying to run Travis
jiridanek commented on a change in pull request #1419: URL: https://github.com/apache/qpid-dispatch/pull/1419#discussion_r744823738 ## File path: src/alloc_pool.c ## @@ -511,7 +513,9 @@ void qd_dealloc(qd_alloc_type_desc_t *desc, qd_alloc_pool_t **tpool, char *p) sys_mutex_unlock(desc->lock); } - +// use-after-free; no way to check if memory is freed before +// accessing it from `qd_alloc_deref_safe_ptr` +ATTRIBUTE_NO_SANITIZE_ADDRESS Review comment: This macro should be also made to work for TSan. TSan does check for some invalid accesses and it barfs on this one. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2206) ASAN use-after-free of qdr_link_t by I/O thread
[
https://issues.apache.org/jira/browse/DISPATCH-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440530#comment-17440530
]
Ganesh Murthy commented on DISPATCH-2206:
-
[~jdanek] can you please get a backtrace of where the qdr_link_t object was
freed? Thanks
> ASAN use-after-free of qdr_link_t by I/O thread
> ---
>
> Key: DISPATCH-2206
> URL: https://issues.apache.org/jira/browse/DISPATCH-2206
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.16.1
>Reporter: Ken Giusti
>Priority: Major
> Labels: asan
> Fix For: 1.19.0
>
>
> [https://github.com/apache/qpid-dispatch/blob/main/src/router_core/connections.c#L1344]
>
> {{27: ==3859==ERROR: AddressSanitizer: use-after-poison on address
> 0x61700017e030 at pc 0x56212343cdac bp 0x7f9d33c40c90 sp 0x7f9d33c40c80 }}
> {{ }}{{}}
> 27: READ of size 8 at 0x61700017e030 thread T2
> {{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{ }}{{}}
> 27: #0 0x56212343cdab in qdr_link_get_context
> ../src/router_core/connections.c:498
> {{}}{{ }}{{}}
> 27: #1 0x56212352ec25 in CORE_link_second_attach ../src/router_node.c:1729
> {{}}{{ }}{{}}
> 27: #2 0x5621234388df in qdr_connection_process
> ../src/router_core/connections.c:355
> {{}}{{ }}{{}}
> 27: #3 0x56212338eccf in writable_handler ../src/container.c:396
> {{}}{{ }}{{}}
> 27: #4 0x56212338eccf in qd_container_handle_event ../src/container.c:748
> {{}}{{ }}{{}}
> 27: #5 0x562123547289 in handle ../src/server.c:1108
> {{}}{{ }}{{}}
> 27: #6 0x562123554c9f in thread_run ../src/server.c:1133
> {{}}{{ }}{{}}
> 27: #7 0x7f9d3ba6c608 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> {{}}{{ }}{{}}
> 27: #8 0x7f9d3ac33292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: 0x61700017e030 is located 176 bytes inside of 704-byte region
> [0x61700017df80,0x61700017e240)
> {{}}{{ }}{{}}
> 27: allocated by thread T2 here:
> {{}}{{ }}{{}}
> 27: #0 0x7f9d3bfd9aa5 in posix_memalign
> (/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5)
> {{}}{{ }}{{}}
> 27: #1 0x5621233247b0 in qd_alloc ../src/alloc_pool.c:396
> {{}}{{ }}{{}}
> 27: #2 0x56212343d4c9 in qdr_link_first_attach
> ../src/router_core/connections.c:592
> {{}}{{ }}{{}}
> 27: #3 0x56212352dde9 in AMQP_outgoing_link_handler
> ../src/router_node.c:1018
> {{}}{{ }}{{}}
> 27: #4 0x562123547289 in handle ../src/server.c:1108
> {{}}{{ }}{{}}
> 27: #5 0x562123554c9f in thread_run ../src/server.c:1133
> {{}}{{ }}{{}}
> 27: #6 0x7f9d3ba6c608 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: Thread T2 created by T0 here:
> {{}}{{ }}{{}}
> 27: #0 0x7f9d3bf05805 in pthread_create
> (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
> {{}}{{ }}{{}}
> 27: #1 0x562123403bcf in sys_thread ../src/posix/threading.c:181
> {{}}{{ }}{{}}
> 27: #2 0x56212355541e in qd_server_run ../src/server.c:1522
> {{}}{{ }}{{}}
> 27: #3 0x56212359f46c in main_process ../router/src/main.c:115
> {{}}{{ }}{{}}
> 27: #4 0x56212329bc50 in main ../router/src/main.c:369
> {{}}{{ }}{{}}
> 27: #5 0x7f9d3ab380b2 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: SUMMARY: AddressSanitizer: use-after-poison
> ../src/router_core/connections.c:498 in qdr_link_get_context
> {{}}{{ }}{{}}
> 27: Shadow bytes around the buggy address:
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bb0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bc0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bd0: f7 f7 f7 f7 f7 f7 f7 00 fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> {{}}{{ }}{{}}
> 27: =>0x0c2e80027c00: 00 00 f7 f7 f7 f7[f7]f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c10: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c20: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c30: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c40: f7 f7 f7 f7 f7 f7 f7 00 fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: Shadow byte legend (one shadow byte represents 8 application bytes):
> {{}}{{ }}{{}}
> 27: Addressable: 00
> {{}}{{ }}{{}}
> 27: Partially addressable: 01 02 03 04 05 06 07
> {{}}{{ }}{{}}
> 27: Heap left redzone: fa
> {{}}{{ }}{{}}
> 27: Freed heap region: fd
> {{}}{{ }}{{}}
> 27: Stack left redzone:
[jira] [Comment Edited] (DISPATCH-1786) system_tests_fallback_dest failing in test_31_switchover_local_interior_alt_remote_interior
[
https://issues.apache.org/jira/browse/DISPATCH-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440480#comment-17440480
]
Ganesh Murthy edited comment on DISPATCH-1786 at 11/8/21, 2:25 PM:
---
This test and other switchover tests have been commented out. [~kgiusti] is
working on a fix to uncomment those tests.
was (Author: ganeshmurthy):
This test and other switchover tests have been commented out. [~kgiusti] is
working on a fix to uncomment those t
> system_tests_fallback_dest failing in
> test_31_switchover_local_interior_alt_remote_interior
> ---
>
> Key: DISPATCH-1786
> URL: https://issues.apache.org/jira/browse/DISPATCH-1786
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Tests
>Affects Versions: 1.14.0
>Reporter: Ganesh Murthy
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.18.0
>
> Attachments: DISPATCH-1786-fallback-test-fail-analysis.txt
>
>
> {noformat}
> 63: Test command: /usr/bin/python "/foo/qpid-dispatch/build/tests/run.py"
> "-m" "unittest" "-v" "system_tests_fallback_dest"
> 63: Test timeout computed to be: 600
> 63: test_01_sender_first_primary_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_02_sender_first_fallback_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_03_sender_first_primary_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_04_sender_first_fallback_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_05_sender_first_primary_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_06_sender_first_fallback_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_07_sender_first_primary_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_08_sender_first_fallback_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_09_sender_first_primary_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_10_sender_first_fallback_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_11_sender_first_primary_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_12_sender_first_fallback_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_13_receiver_first_primary_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_14_receiver_first_fallback_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_15_receiver_first_primary_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_16_receiver_first_fallback_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_17_receiver_first_primary_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_18_receiver_first_fallback_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_19_receiver_first_primary_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_20_receiver_first_fallback_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_21_receiver_first_primary_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_22_receiver_first_fallback_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_23_receiver_first_primary_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_24_receiver_first_fallback_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_25_switchover_same_edge (system_tests_fallback_dest.RouterTest) ...
> ok
> 63: test_26_switchover_same_interior (system_tests_fallback_dest.RouterTest)
> ... ok
> 63: test_27_switchover_local_edge_alt_remote_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_28_switchover_local_edge_alt_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_29_switchover_local_edge_pri_remote_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_30_switchover_local_interior_pri_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_31_switchover_local_interior_alt_remote_interior
> (system_tests_fallback_dest.RouterTest) ... FAIL
> 63: test_32_switchover_local_interior_alt_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_33_switchover_local_interior_pri_remote_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_34_switchover_local_interior_pri_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_35_switchover_mix_1 (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_36_switchover_mix_2 (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_37_swi
[jira] [Commented] (DISPATCH-2206) ASAN use-after-free of qdr_link_t by I/O thread
[
https://issues.apache.org/jira/browse/DISPATCH-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440500#comment-17440500
]
Ganesh Murthy commented on DISPATCH-2206:
-
DISPATCH-2274 is attempting to fix the use after free on qd_link_t object. This
one is use after free of the qdr_link_t object.
> ASAN use-after-free of qdr_link_t by I/O thread
> ---
>
> Key: DISPATCH-2206
> URL: https://issues.apache.org/jira/browse/DISPATCH-2206
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.16.1
>Reporter: Ken Giusti
>Priority: Major
> Labels: asan
> Fix For: 1.19.0
>
>
> [https://github.com/apache/qpid-dispatch/blob/main/src/router_core/connections.c#L1344]
>
> {{27: ==3859==ERROR: AddressSanitizer: use-after-poison on address
> 0x61700017e030 at pc 0x56212343cdac bp 0x7f9d33c40c90 sp 0x7f9d33c40c80 }}
> {{ }}{{}}
> 27: READ of size 8 at 0x61700017e030 thread T2
> {{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{}}{{ }}{{}}
> 27: #0 0x56212343cdab in qdr_link_get_context
> ../src/router_core/connections.c:498
> {{}}{{ }}{{}}
> 27: #1 0x56212352ec25 in CORE_link_second_attach ../src/router_node.c:1729
> {{}}{{ }}{{}}
> 27: #2 0x5621234388df in qdr_connection_process
> ../src/router_core/connections.c:355
> {{}}{{ }}{{}}
> 27: #3 0x56212338eccf in writable_handler ../src/container.c:396
> {{}}{{ }}{{}}
> 27: #4 0x56212338eccf in qd_container_handle_event ../src/container.c:748
> {{}}{{ }}{{}}
> 27: #5 0x562123547289 in handle ../src/server.c:1108
> {{}}{{ }}{{}}
> 27: #6 0x562123554c9f in thread_run ../src/server.c:1133
> {{}}{{ }}{{}}
> 27: #7 0x7f9d3ba6c608 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> {{}}{{ }}{{}}
> 27: #8 0x7f9d3ac33292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: 0x61700017e030 is located 176 bytes inside of 704-byte region
> [0x61700017df80,0x61700017e240)
> {{}}{{ }}{{}}
> 27: allocated by thread T2 here:
> {{}}{{ }}{{}}
> 27: #0 0x7f9d3bfd9aa5 in posix_memalign
> (/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5)
> {{}}{{ }}{{}}
> 27: #1 0x5621233247b0 in qd_alloc ../src/alloc_pool.c:396
> {{}}{{ }}{{}}
> 27: #2 0x56212343d4c9 in qdr_link_first_attach
> ../src/router_core/connections.c:592
> {{}}{{ }}{{}}
> 27: #3 0x56212352dde9 in AMQP_outgoing_link_handler
> ../src/router_node.c:1018
> {{}}{{ }}{{}}
> 27: #4 0x562123547289 in handle ../src/server.c:1108
> {{}}{{ }}{{}}
> 27: #5 0x562123554c9f in thread_run ../src/server.c:1133
> {{}}{{ }}{{}}
> 27: #6 0x7f9d3ba6c608 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: Thread T2 created by T0 here:
> {{}}{{ }}{{}}
> 27: #0 0x7f9d3bf05805 in pthread_create
> (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
> {{}}{{ }}{{}}
> 27: #1 0x562123403bcf in sys_thread ../src/posix/threading.c:181
> {{}}{{ }}{{}}
> 27: #2 0x56212355541e in qd_server_run ../src/server.c:1522
> {{}}{{ }}{{}}
> 27: #3 0x56212359f46c in main_process ../router/src/main.c:115
> {{}}{{ }}{{}}
> 27: #4 0x56212329bc50 in main ../router/src/main.c:369
> {{}}{{ }}{{}}
> 27: #5 0x7f9d3ab380b2 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
> {{}}{{ }}{{}}
> 27:
> {{}}{{ }}{{}}
> 27: SUMMARY: AddressSanitizer: use-after-poison
> ../src/router_core/connections.c:498 in qdr_link_get_context
> {{}}{{ }}{{}}
> 27: Shadow bytes around the buggy address:
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bb0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bc0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bd0: f7 f7 f7 f7 f7 f7 f7 00 fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> {{}}{{ }}{{}}
> 27: =>0x0c2e80027c00: 00 00 f7 f7 f7 f7[f7]f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c10: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c20: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c30: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c40: f7 f7 f7 f7 f7 f7 f7 00 fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: 0x0c2e80027c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> {{}}{{ }}{{}}
> 27: Shadow byte legend (one shadow byte represents 8 application bytes):
> {{}}{{ }}{{}}
> 27: Addressable: 00
> {{}}{{ }}{{}}
> 27: Partially addressable: 01 02 03 04 05 06 07
> {{}}{{ }}{{}}
> 27: Heap left redzone: fa
> {{}}{{ }}{{}}
> 27: Freed heap region: fd
> {{}
[jira] [Resolved] (DISPATCH-1786) system_tests_fallback_dest failing in test_31_switchover_local_interior_alt_remote_interior
[
https://issues.apache.org/jira/browse/DISPATCH-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1786.
-
Fix Version/s: 1.18.0
(was: 1.15.0)
Resolution: Fixed
This test and other switchover tests have been commented out. [~kgiusti] is
working on a fix to uncomment those t
> system_tests_fallback_dest failing in
> test_31_switchover_local_interior_alt_remote_interior
> ---
>
> Key: DISPATCH-1786
> URL: https://issues.apache.org/jira/browse/DISPATCH-1786
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Tests
>Affects Versions: 1.14.0
>Reporter: Ganesh Murthy
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.18.0
>
> Attachments: DISPATCH-1786-fallback-test-fail-analysis.txt
>
>
> {noformat}
> 63: Test command: /usr/bin/python "/foo/qpid-dispatch/build/tests/run.py"
> "-m" "unittest" "-v" "system_tests_fallback_dest"
> 63: Test timeout computed to be: 600
> 63: test_01_sender_first_primary_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_02_sender_first_fallback_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_03_sender_first_primary_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_04_sender_first_fallback_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_05_sender_first_primary_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_06_sender_first_fallback_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_07_sender_first_primary_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_08_sender_first_fallback_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_09_sender_first_primary_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_10_sender_first_fallback_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_11_sender_first_primary_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_12_sender_first_fallback_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_13_receiver_first_primary_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_14_receiver_first_fallback_same_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_15_receiver_first_primary_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_16_receiver_first_fallback_same_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_17_receiver_first_primary_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_18_receiver_first_fallback_interior_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_19_receiver_first_primary_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_20_receiver_first_fallback_edge_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_21_receiver_first_primary_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_22_receiver_first_fallback_interior_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_23_receiver_first_primary_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_24_receiver_first_fallback_edge_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_25_switchover_same_edge (system_tests_fallback_dest.RouterTest) ...
> ok
> 63: test_26_switchover_same_interior (system_tests_fallback_dest.RouterTest)
> ... ok
> 63: test_27_switchover_local_edge_alt_remote_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_28_switchover_local_edge_alt_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_29_switchover_local_edge_pri_remote_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_30_switchover_local_interior_pri_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_31_switchover_local_interior_alt_remote_interior
> (system_tests_fallback_dest.RouterTest) ... FAIL
> 63: test_32_switchover_local_interior_alt_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_33_switchover_local_interior_pri_remote_interior
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_34_switchover_local_interior_pri_remote_edge
> (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_35_switchover_mix_1 (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_36_switchover_mix_2 (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_37_switchover_mix_3 (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_38_switchover_mix_4 (system_tests_fallback_dest.RouterTest) ... ok
> 63: test_39_auto_link_sende
[jira] [Commented] (PROTON-2396) [cpp] Seed in uuid.cpp can lead to duplicates
[
https://issues.apache.org/jira/browse/PROTON-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440418#comment-17440418
]
ASF GitHub Bot commented on PROTON-2396:
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744660582
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
(assuming that there is not something else which prevents concurrent
use; I think there isn't)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [cpp] Seed in uuid.cpp can lead to duplicates
> -
>
> Key: PROTON-2396
> URL: https://issues.apache.org/jira/browse/PROTON-2396
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Environment: RHEL7 running in OpenStack
> docker-ce 19.03.5
> qpid-proton 0.28.0
> qpid-cpp 1.37.0
>Reporter: Ryan Herbert
>Assignee: Rakhi Kumari
>Priority: Major
>
> The random number seed used in qpid-proton/cpp/src/uuid.cpp is based on the
> current time and the PID of the running process. When starting multiple
> proton instances simultaneously in Docker containers via automated
> deployment, there is a high probability that multiple instances will get the
> same seed since the PID within the Docker container is consistent and the
> same across multiple copies of the same Docker container.
> This results in duplicate link names when binding to exchanges. When this
> happens, the queue gets bound to two different exchanges, and requests sent
> to one exchange will get responses from both services.
> To work around this error, we are specifying the link name via
> sender_options/receiver_options every time we open a new sender/receiver, and
> we also specify the container_id in connection_options. We are using
> std::mt19937_64 seeded with
> std::chrono::system_clock::now().time_since_epoch().count() to generate the
> random part of our link names, which seems to have enough randomness that it
> has eliminated the problem for us.
> As pointed out in the Proton user forum, std::random_device is probably a
> better choice for initializing the seed.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #340: PROTON-2396: [WIP] Use random_device for seed initialization in uuid.cpp
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744660582
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
(assuming that there is not something else which prevents concurrent
use; I think there isn't)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2187) Timeout in system_tests_tcp_adaptor setup; wait for echo server addresses to propagate
[
https://issues.apache.org/jira/browse/DISPATCH-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk reassigned DISPATCH-2187:
Assignee: (was: Jiri Daněk)
> Timeout in system_tests_tcp_adaptor setup; wait for echo server addresses to
> propagate
> --
>
> Key: DISPATCH-2187
> URL: https://issues.apache.org/jira/browse/DISPATCH-2187
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://github.com/apache/qpid-dispatch/pull/1276/checks?check_run_id=2931065190#step:25:6130
> There are .zipped TRACE logs available in github job artifacts for download.
> {noformat}
> test 71
> Start 71: system_tests_tcp_adaptor
> 71: Test command: /usr/bin/python3
> "/__w/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/run.py" "-m"
> "pytest" "-vs" "--junit-prefix=pytest.system_tests_tcp_adaptor"
> "--junit-xml=junitxmls/system_tests_tcp_adaptor.xml" "--pyargs"
> "system_tests_tcp_adaptor"
> 71: Test timeout computed to be: 1200
> 71: = test session starts
> ==
> 71: platform linux -- Python 3.9.5, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 --
> /usr/bin/python3
> 71: cachedir: .pytest_cache
> 71: rootdir: /__w/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests,
> configfile: tox.ini
> 71: collecting ... collected 11 items
> 71:
> 71: ::TcpAdaptor::test_01_tcp_basic_connectivity 2021-06-28 11:22:12.450985
> SERVER (info) Container Name: TCP_TEST
> 71: 2021-06-28 11:22:12.451571 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_INTA'
> 71: 2021-06-28 11:22:12.451971 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_INTB'
> 71: 2021-06-28 11:22:12.452475 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_INTC'
> 71: 2021-06-28 11:22:12.452971 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EA1'
> 71: 2021-06-28 11:22:12.453447 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EA2'
> 71: 2021-06-28 11:22:12.454621 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EB1'
> 71: 2021-06-28 11:22:12.455364 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EB2'
> 71: 2021-06-28 11:22:12.456025 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EC1'
> 71: 2021-06-28 11:22:12.457192 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EC2'
> 71: 2021-06-28 11:22:12.457860 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor NS_EC2_CONN_STALL'
> 69: ::Http1AdaptorEdge2EdgeTest::test_01_concurrent_requests PASSED
> 71: 2021-06-28 11:22:22.297788 TCP_TEST INTA waiting for connection to INTB
> 71: 2021-06-28 11:22:22.419440 TCP_TEST INTB waiting for connection to INTA
> 71: 2021-06-28 11:22:22.513287 TCP_TEST INTB waiting for connection to INTC
> 71: 2021-06-28 11:22:22.575660 TCP_TEST INTC waiting for connection to INTB
> 71: 2021-06-28 11:22:22.680197 TCP_TEST INTA_amqp=22045
> 71: 2021-06-28 11:22:22.680577 TCP_TEST INTA_echo_server=22035
> 71: 2021-06-28 11:22:22.680753 TCP_TEST INTA_echo_listener_for_INTA=22046
> 71: 2021-06-28 11:22:22.680796 TCP_TEST INTA_echo_listener_for_INTB=22047
> 71: 2021-06-28 11:22:22.680834 TCP_TEST INTA_echo_listener_for_INTC=22048
> 71: 2021-06-28 11:22:22.680870 TCP_TEST INTA_echo_listener_for_EA1=22049
> 71: 2021-06-28 11:22:22.680906 TCP_TEST INTA_echo_listener_for_EA2=22050
> 71: 2021-06-28 11:22:22.680942 TCP_TEST INTA_echo_listener_for_EB1=22051
> 71: 2021-06-28 11:22:22.681073 TCP_TEST INTA_echo_listener_for_EB2=22052
> 71: 2021-06-28 11:22:22.681129 TCP_TEST INTA_echo_listener_for_EC1=22053
> 71: 2021-06-28 11:22:22.681166 TCP_TEST INTA_echo_listener_for_EC2=22054
> 71: 2021-06-28 11:22:22.681339 TCP_TEST INTA_nodest_listener=22055
> 71: 2021-06-28 11:22:22.681381 TCP_TEST INTB_amqp=22056
> 71: 2021-06-28 11:22:22.681417 TCP_TEST INTB_echo_server=22036
> 71: 2021-06-28 11:22:22.681452 TCP_TEST INTB_echo_listener_for_INTA=22057
> 71: 2021-06-28 11:22:22.681487 TCP_TEST INTB_echo_listener_for_INTB=22058
> 71: 2021-06-28 11:22:22.681523 TCP_TEST INTB_echo_listener_for_INTC=22059
> 71: 2021-06-28 11:22:22.681558 TCP_TEST INTB_echo_listener_for_EA1=22060
> 71: 2021-06-28 11:22:22.681593 TCP_TEST INTB_echo_listener_for_EA2=22061
> 71: 2021-06-28 11:22:22.681628 TCP_TEST INTB_echo_listener_for_EB1=22062
> 71: 2021-06-28 11:22:22.681663 TCP_TEST INTB_echo_listener_for_EB2=22063
> 71: 2021-06-28 11:22:22.681698 TCP_TEST INTB_echo_listener_for_EC1=22064
> 71: 2021-06-28 11:22:22.681733 TCP_TEST INTB_echo_listener_for_EC2=22065
> 71: 2021-06-28 11:22:22.681768 TCP_TEST INTB_nodest_listener=22066
> 71: 2021-06-28 11:22:22.681803 TCP_TEST INTC_amqp=22067
> 71: 2021-06-28 11:22:22.681838 TCP_TEST INTC_echo_server=22037
> 71: 202
[jira] [Assigned] (DISPATCH-2187) Timeout in system_tests_tcp_adaptor setup; wait for echo server addresses to propagate
[
https://issues.apache.org/jira/browse/DISPATCH-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk reassigned DISPATCH-2187:
Assignee: Jiri Daněk
> Timeout in system_tests_tcp_adaptor setup; wait for echo server addresses to
> propagate
> --
>
> Key: DISPATCH-2187
> URL: https://issues.apache.org/jira/browse/DISPATCH-2187
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
>
> https://github.com/apache/qpid-dispatch/pull/1276/checks?check_run_id=2931065190#step:25:6130
> There are .zipped TRACE logs available in github job artifacts for download.
> {noformat}
> test 71
> Start 71: system_tests_tcp_adaptor
> 71: Test command: /usr/bin/python3
> "/__w/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/run.py" "-m"
> "pytest" "-vs" "--junit-prefix=pytest.system_tests_tcp_adaptor"
> "--junit-xml=junitxmls/system_tests_tcp_adaptor.xml" "--pyargs"
> "system_tests_tcp_adaptor"
> 71: Test timeout computed to be: 1200
> 71: = test session starts
> ==
> 71: platform linux -- Python 3.9.5, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 --
> /usr/bin/python3
> 71: cachedir: .pytest_cache
> 71: rootdir: /__w/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests,
> configfile: tox.ini
> 71: collecting ... collected 11 items
> 71:
> 71: ::TcpAdaptor::test_01_tcp_basic_connectivity 2021-06-28 11:22:12.450985
> SERVER (info) Container Name: TCP_TEST
> 71: 2021-06-28 11:22:12.451571 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_INTA'
> 71: 2021-06-28 11:22:12.451971 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_INTB'
> 71: 2021-06-28 11:22:12.452475 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_INTC'
> 71: 2021-06-28 11:22:12.452971 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EA1'
> 71: 2021-06-28 11:22:12.453447 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EA2'
> 71: 2021-06-28 11:22:12.454621 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EB1'
> 71: 2021-06-28 11:22:12.455364 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EB2'
> 71: 2021-06-28 11:22:12.456025 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EC1'
> 71: 2021-06-28 11:22:12.457192 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor ES_EC2'
> 71: 2021-06-28 11:22:12.457860 TCP_TEST Launching echo server 'ECHO_SERVER
> TcpAdaptor NS_EC2_CONN_STALL'
> 69: ::Http1AdaptorEdge2EdgeTest::test_01_concurrent_requests PASSED
> 71: 2021-06-28 11:22:22.297788 TCP_TEST INTA waiting for connection to INTB
> 71: 2021-06-28 11:22:22.419440 TCP_TEST INTB waiting for connection to INTA
> 71: 2021-06-28 11:22:22.513287 TCP_TEST INTB waiting for connection to INTC
> 71: 2021-06-28 11:22:22.575660 TCP_TEST INTC waiting for connection to INTB
> 71: 2021-06-28 11:22:22.680197 TCP_TEST INTA_amqp=22045
> 71: 2021-06-28 11:22:22.680577 TCP_TEST INTA_echo_server=22035
> 71: 2021-06-28 11:22:22.680753 TCP_TEST INTA_echo_listener_for_INTA=22046
> 71: 2021-06-28 11:22:22.680796 TCP_TEST INTA_echo_listener_for_INTB=22047
> 71: 2021-06-28 11:22:22.680834 TCP_TEST INTA_echo_listener_for_INTC=22048
> 71: 2021-06-28 11:22:22.680870 TCP_TEST INTA_echo_listener_for_EA1=22049
> 71: 2021-06-28 11:22:22.680906 TCP_TEST INTA_echo_listener_for_EA2=22050
> 71: 2021-06-28 11:22:22.680942 TCP_TEST INTA_echo_listener_for_EB1=22051
> 71: 2021-06-28 11:22:22.681073 TCP_TEST INTA_echo_listener_for_EB2=22052
> 71: 2021-06-28 11:22:22.681129 TCP_TEST INTA_echo_listener_for_EC1=22053
> 71: 2021-06-28 11:22:22.681166 TCP_TEST INTA_echo_listener_for_EC2=22054
> 71: 2021-06-28 11:22:22.681339 TCP_TEST INTA_nodest_listener=22055
> 71: 2021-06-28 11:22:22.681381 TCP_TEST INTB_amqp=22056
> 71: 2021-06-28 11:22:22.681417 TCP_TEST INTB_echo_server=22036
> 71: 2021-06-28 11:22:22.681452 TCP_TEST INTB_echo_listener_for_INTA=22057
> 71: 2021-06-28 11:22:22.681487 TCP_TEST INTB_echo_listener_for_INTB=22058
> 71: 2021-06-28 11:22:22.681523 TCP_TEST INTB_echo_listener_for_INTC=22059
> 71: 2021-06-28 11:22:22.681558 TCP_TEST INTB_echo_listener_for_EA1=22060
> 71: 2021-06-28 11:22:22.681593 TCP_TEST INTB_echo_listener_for_EA2=22061
> 71: 2021-06-28 11:22:22.681628 TCP_TEST INTB_echo_listener_for_EB1=22062
> 71: 2021-06-28 11:22:22.681663 TCP_TEST INTB_echo_listener_for_EB2=22063
> 71: 2021-06-28 11:22:22.681698 TCP_TEST INTB_echo_listener_for_EC1=22064
> 71: 2021-06-28 11:22:22.681733 TCP_TEST INTB_echo_listener_for_EC2=22065
> 71: 2021-06-28 11:22:22.681768 TCP_TEST INTB_nodest_listener=22066
> 71: 2021-06-28 11:22:22.681803 TCP_TEST INTC_amqp=22067
> 71: 2021-06-28 11:22:22.681838 TCP_TEST INTC_echo
[jira] [Commented] (PROTON-2396) [cpp] Seed in uuid.cpp can lead to duplicates
[
https://issues.apache.org/jira/browse/PROTON-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440318#comment-17440318
]
ASF GitHub Bot commented on PROTON-2396:
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744535498
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
Instead of having the seed_, the variables could be private static in
the uuid class, btw.
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
Instead of having the seed_ separately, the variables could be private
static in the uuid class, btw.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [cpp] Seed in uuid.cpp can lead to duplicates
> -
>
> Key: PROTON-2396
> URL: https://issues.apache.org/jira/browse/PROTON-2396
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Environment: RHEL7 running in OpenStack
> docker-ce 19.03.5
> qpid-proton 0.28.0
> qpid-cpp 1.37.0
>Reporter: Ryan Herbert
>Assignee: Rakhi Kumari
>Priority: Major
>
> The random number seed used in qpid-proton/cpp/src/uuid.cpp is based on the
> current time and the PID of the running process. When starting multiple
> proton instances simultaneously in Docker containers via automated
> deployment, there is a high probability that multiple instances will get the
> same seed since the PID within the Docker container is consistent and the
> same across multiple copies of the same Docker container.
> This results in duplicate link names when binding to exchanges. When this
> happens, the queue gets bound to two different exchanges, and requests sent
> to one exchange will get responses from both services.
> To work around this error, we are specifying the link name via
> sender_options/receiver_options every time we open a new sender/receiver, and
> we also specify the container_id in connection_options. We are using
> std::mt19937_64 seeded with
> std::chrono::system_clock::now().time_since_epoch().count() to generate the
> random part of our link names, which seems to have enough randomness that it
> has eliminated the problem for us.
> As pointed out in the Proton user forum, std::random_device is probably a
> better choice for initializing the seed.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #340: PROTON-2396: [WIP] Use random_device for seed initialization in uuid.cpp
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744535498
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
Instead of having the seed_, the variables could be private static in
the uuid class, btw.
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
Instead of having the seed_ separately, the variables could be private
static in the uuid class, btw.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2396) [cpp] Seed in uuid.cpp can lead to duplicates
[
https://issues.apache.org/jira/browse/PROTON-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440317#comment-17440317
]
ASF GitHub Bot commented on PROTON-2396:
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744534838
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
Threadsafety, I almost forgot! The std:: random stuff is not threadsafe,
so maybe it should be declared thread_local as that would be easiest.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [cpp] Seed in uuid.cpp can lead to duplicates
> -
>
> Key: PROTON-2396
> URL: https://issues.apache.org/jira/browse/PROTON-2396
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Environment: RHEL7 running in OpenStack
> docker-ce 19.03.5
> qpid-proton 0.28.0
> qpid-cpp 1.37.0
>Reporter: Ryan Herbert
>Assignee: Rakhi Kumari
>Priority: Major
>
> The random number seed used in qpid-proton/cpp/src/uuid.cpp is based on the
> current time and the PID of the running process. When starting multiple
> proton instances simultaneously in Docker containers via automated
> deployment, there is a high probability that multiple instances will get the
> same seed since the PID within the Docker container is consistent and the
> same across multiple copies of the same Docker container.
> This results in duplicate link names when binding to exchanges. When this
> happens, the queue gets bound to two different exchanges, and requests sent
> to one exchange will get responses from both services.
> To work around this error, we are specifying the link name via
> sender_options/receiver_options every time we open a new sender/receiver, and
> we also specify the container_id in connection_options. We are using
> std::mt19937_64 seeded with
> std::chrono::system_clock::now().time_since_epoch().count() to generate the
> random part of our link names, which seems to have enough randomness that it
> has eliminated the problem for us.
> As pointed out in the Proton user forum, std::random_device is probably a
> better choice for initializing the seed.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #340: PROTON-2396: [WIP] Use random_device for seed initialization in uuid.cpp
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744534838
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
Threadsafety, I almost forgot! The std:: random stuff is not threadsafe,
so maybe it should be declared thread_local as that would be easiest.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2254) Relative paths in CMake share
[
https://issues.apache.org/jira/browse/PROTON-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440312#comment-17440312
]
ASF GitHub Bot commented on PROTON-2254:
jiridanek commented on pull request #335:
URL: https://github.com/apache/qpid-proton/pull/335#issuecomment-962950720
Thanks for the review, I must've missed the notification about it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relative paths in CMake share
> -
>
> Key: PROTON-2254
> URL: https://issues.apache.org/jira/browse/PROTON-2254
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build, cpp-binding, proton-c
>Affects Versions: proton-c-0.31.0
> Environment: Debian Linux; build Proton then Dispatch into each their
> own `DESTDIR`. This is done by our "layered build" system,
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_proton.sh and
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_dispatch.sh
>Reporter: Rick van Rein
>Assignee: Jiri Daněk
>Priority: Minor
> Labels: cmake, install, proton
> Fix For: proton-c-0.36.0
>
> Original Estimate: 0.25h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> This sequency installs well:
> {noformat}
> cmake
> make
> make DESTDIR=/some/where install
> {noformat}
> However, further use of the installation fails, because of strict
> dependencies on the *installed* paths in files like `ProtonConfig.cmake`:
> {noformat}
> set_target_properties(Proton::core
> PROPERTIES
> IMPORTED_LOCATION "/usr/local/lib/libqpid-proton-core.so"
> IMPORTED_LOCATION_DEBUG "/usr/local/lib/libqpid-proton-core.so"
> INTERFACE_INCLUDE_DIRECTORIES "${Proton_Core_INCLUDE_DIRS}")
> {noformat}
> **What would work:** First switch to the `DESTDIR`, then continue building
> something like Qpid Dispatch Router.
> **Solution:** Use relative directories, like in:
> {noformat}
> # Compute the installation prefix relative to this file.
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> if(_IMPORT_PREFIX STREQUAL "/")
> set(_IMPORT_PREFIX "")
> endif()
> {noformat}
> **Work-around:** An unhappy quickfix is
> {noformat}
> find /some/where -name *.cmake -exec \
> sed -i "s+/usr/+/some/where/usr/+g" {} \;
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on pull request #335: PROTON-2254 Generate correct relocatable pc files
jiridanek commented on pull request #335: URL: https://github.com/apache/qpid-proton/pull/335#issuecomment-962950720 Thanks for the review, I must've missed the notification about it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2254) Relative paths in CMake share
[
https://issues.apache.org/jira/browse/PROTON-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440307#comment-17440307
]
ASF GitHub Bot commented on PROTON-2254:
jiridanek commented on a change in pull request #335:
URL: https://github.com/apache/qpid-proton/pull/335#discussion_r744527069
##
File path: c/src/libqpid-proton-core.pc.in
##
@@ -17,10 +17,10 @@
* under the License.
*/
-prefix=@PREFIX@
-exec_prefix=@EXEC_PREFIX@
-libdir=@LIBDIR@
-includedir=@INCLUDEDIR@
+prefix=${pcfiledir}/../..
+exec_prefix=${prefix}
Review comment:
I'm reasonably sure, because everybody does it this way. I guess I need
some more pkgconfig education too, to be 100% certain why.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relative paths in CMake share
> -
>
> Key: PROTON-2254
> URL: https://issues.apache.org/jira/browse/PROTON-2254
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build, cpp-binding, proton-c
>Affects Versions: proton-c-0.31.0
> Environment: Debian Linux; build Proton then Dispatch into each their
> own `DESTDIR`. This is done by our "layered build" system,
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_proton.sh and
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_dispatch.sh
>Reporter: Rick van Rein
>Assignee: Jiri Daněk
>Priority: Minor
> Labels: cmake, install, proton
> Fix For: proton-c-0.36.0
>
> Original Estimate: 0.25h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> This sequency installs well:
> {noformat}
> cmake
> make
> make DESTDIR=/some/where install
> {noformat}
> However, further use of the installation fails, because of strict
> dependencies on the *installed* paths in files like `ProtonConfig.cmake`:
> {noformat}
> set_target_properties(Proton::core
> PROPERTIES
> IMPORTED_LOCATION "/usr/local/lib/libqpid-proton-core.so"
> IMPORTED_LOCATION_DEBUG "/usr/local/lib/libqpid-proton-core.so"
> INTERFACE_INCLUDE_DIRECTORIES "${Proton_Core_INCLUDE_DIRS}")
> {noformat}
> **What would work:** First switch to the `DESTDIR`, then continue building
> something like Qpid Dispatch Router.
> **Solution:** Use relative directories, like in:
> {noformat}
> # Compute the installation prefix relative to this file.
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> if(_IMPORT_PREFIX STREQUAL "/")
> set(_IMPORT_PREFIX "")
> endif()
> {noformat}
> **Work-around:** An unhappy quickfix is
> {noformat}
> find /some/where -name *.cmake -exec \
> sed -i "s+/usr/+/some/where/usr/+g" {} \;
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2254) Relative paths in CMake share
[
https://issues.apache.org/jira/browse/PROTON-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440309#comment-17440309
]
ASF GitHub Bot commented on PROTON-2254:
jiridanek commented on a change in pull request #335:
URL: https://github.com/apache/qpid-proton/pull/335#discussion_r744527651
##
File path: cpp/libqpid-proton-cpp.pc.in
##
@@ -17,10 +17,10 @@
* under the License.
*/
-prefix=@PREFIX@
-exec_prefix=@EXEC_PREFIX@
-libdir=@LIBDIR@
-includedir=@INCLUDEDIR@
+prefix=${pcfiledir}/../..
+exec_prefix=${prefix}
+libdir=${prefix}/@INCLUDEDIR@
+includedir=${prefix}/@LIBDIR@
Review comment:
:facepalm:, thanks! Ctrl+C very powerful, me copy nonsense much.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relative paths in CMake share
> -
>
> Key: PROTON-2254
> URL: https://issues.apache.org/jira/browse/PROTON-2254
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build, cpp-binding, proton-c
>Affects Versions: proton-c-0.31.0
> Environment: Debian Linux; build Proton then Dispatch into each their
> own `DESTDIR`. This is done by our "layered build" system,
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_proton.sh and
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_dispatch.sh
>Reporter: Rick van Rein
>Assignee: Jiri Daněk
>Priority: Minor
> Labels: cmake, install, proton
> Fix For: proton-c-0.36.0
>
> Original Estimate: 0.25h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> This sequency installs well:
> {noformat}
> cmake
> make
> make DESTDIR=/some/where install
> {noformat}
> However, further use of the installation fails, because of strict
> dependencies on the *installed* paths in files like `ProtonConfig.cmake`:
> {noformat}
> set_target_properties(Proton::core
> PROPERTIES
> IMPORTED_LOCATION "/usr/local/lib/libqpid-proton-core.so"
> IMPORTED_LOCATION_DEBUG "/usr/local/lib/libqpid-proton-core.so"
> INTERFACE_INCLUDE_DIRECTORIES "${Proton_Core_INCLUDE_DIRS}")
> {noformat}
> **What would work:** First switch to the `DESTDIR`, then continue building
> something like Qpid Dispatch Router.
> **Solution:** Use relative directories, like in:
> {noformat}
> # Compute the installation prefix relative to this file.
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> if(_IMPORT_PREFIX STREQUAL "/")
> set(_IMPORT_PREFIX "")
> endif()
> {noformat}
> **Work-around:** An unhappy quickfix is
> {noformat}
> find /some/where -name *.cmake -exec \
> sed -i "s+/usr/+/some/where/usr/+g" {} \;
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #335: PROTON-2254 Generate correct relocatable pc files
jiridanek commented on a change in pull request #335:
URL: https://github.com/apache/qpid-proton/pull/335#discussion_r744527651
##
File path: cpp/libqpid-proton-cpp.pc.in
##
@@ -17,10 +17,10 @@
* under the License.
*/
-prefix=@PREFIX@
-exec_prefix=@EXEC_PREFIX@
-libdir=@LIBDIR@
-includedir=@INCLUDEDIR@
+prefix=${pcfiledir}/../..
+exec_prefix=${prefix}
+libdir=${prefix}/@INCLUDEDIR@
+includedir=${prefix}/@LIBDIR@
Review comment:
:facepalm:, thanks! Ctrl+C very powerful, me copy nonsense much.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #335: PROTON-2254 Generate correct relocatable pc files
jiridanek commented on a change in pull request #335:
URL: https://github.com/apache/qpid-proton/pull/335#discussion_r744527069
##
File path: c/src/libqpid-proton-core.pc.in
##
@@ -17,10 +17,10 @@
* under the License.
*/
-prefix=@PREFIX@
-exec_prefix=@EXEC_PREFIX@
-libdir=@LIBDIR@
-includedir=@INCLUDEDIR@
+prefix=${pcfiledir}/../..
+exec_prefix=${prefix}
Review comment:
I'm reasonably sure, because everybody does it this way. I guess I need
some more pkgconfig education too, to be 100% certain why.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2396) [cpp] Seed in uuid.cpp can lead to duplicates
[
https://issues.apache.org/jira/browse/PROTON-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440305#comment-17440305
]
ASF GitHub Bot commented on PROTON-2396:
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744523432
##
File path: cpp/src/uuid.cpp
##
@@ -70,11 +74,11 @@ uuid uuid::copy(const char* bytes) {
uuid uuid::random() {
uuid bytes;
-int r = std::rand();
+int r = seed_.dist(seed_.engine);
for (size_t i = 0; i < bytes.size(); ++i ) {
bytes[i] = r & 0xFF;
r >>= 8;
-if (!r) r = std::rand();
+if (!r) r = seed_.dist(seed_.engine);
Review comment:
Thinking about the original algorithm, this line means that if there is
a zero byte at the "end" of the random number, it will not be put into the UUID
and a new number will be generated instead. For example, if the `seed_.dist`
before the loop generated a 0, then only the first byte will be put into the
uuid and then immediately a new random number will be generated. I'm trying to
say that the random data in the UUID will be IMO somewhat biased against `\x00`
bytes.
Maybe best to use something like `std::independent_bits_engine` suggested in
the first answer on
https://stackoverflow.com/questions/25298585/efficiently-generating-random-bytes-of-data-in-c11-14
##
File path: cpp/src/uuid.cpp
##
@@ -70,11 +74,11 @@ uuid uuid::copy(const char* bytes) {
uuid uuid::random() {
uuid bytes;
-int r = std::rand();
+int r = seed_.dist(seed_.engine);
Review comment:
std::rand returns numbers from 0 to INT_MAX. You are changing the range
now to include negative numbers. Is it intentional? Does it matter? AFAIK it
does, a little, for the better.
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
-seed() {
+std::random_device device;
+std::mt19937 engine;
+std::uniform_int_distribution dist;
+seed():engine(device()), dist(INT_MIN, INT_MAX) {
Review comment:
```suggestion
std::mt19937 engine(std::random_device{}());
std::uniform_int_distribution dist(INT_MIN, INT_MAX);
seed() {
```
I did not try the above, so maybe I am doing something completely silly, but
to me, if that works, it is a better option. Initializing in the constructor
initializer list seems clumsy, in that you have to make sure the order of the
declared variables and the order in which they are initialized is the same.
The C++ version of `INT_MAX` seems to be
`std::numeric_limits::max()`. Probably not worth using, as it is
significantly longer string to type.
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
I'd rename this struct. At this point it is not a seed, it is the
generator.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [cpp] Seed in uuid.cpp can lead to duplicates
> -
>
> Key: PROTON-2396
> URL: https://issues.apache.org/jira/browse/PROTON-2396
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Environment: RHEL7 running in OpenStack
> docker-ce 19.03.5
> qpid-proton 0.28.0
> qpid-cpp 1.37.0
>Reporter: Ryan Herbert
>Assignee: Rakhi Kumari
>Priority: Major
>
> The random number seed used in qpid-proton/cpp/src/uuid.cpp is based on the
> current time and the PID of the running process. When starting multiple
> proton instances simultaneously in Docker containers via automated
> deployment, there is a high probability that multiple instances will get the
> same seed since the PID within the Docker container is consistent and the
> same across multiple copies of the same Docker container.
> This results in duplicate link names when binding to exchanges. When this
> happens, the queue gets bound to two different exchanges, and requests sent
> to one exchange will get responses from both services.
> To work around this error, we are specifying the link name via
> sender_options/receiver_options every time we open a new sender/receiver, and
> we also specify the container_id in connection_options. We are using
> std::mt19937_64 seeded with
> std::chrono::system_clock::now().time_since_epoch().count() to generate the
> random part of our link names, which seems
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #340: PROTON-2396: [WIP] Use random_device for seed initialization in uuid.cpp
jiridanek commented on a change in pull request #340:
URL: https://github.com/apache/qpid-proton/pull/340#discussion_r744523432
##
File path: cpp/src/uuid.cpp
##
@@ -70,11 +74,11 @@ uuid uuid::copy(const char* bytes) {
uuid uuid::random() {
uuid bytes;
-int r = std::rand();
+int r = seed_.dist(seed_.engine);
for (size_t i = 0; i < bytes.size(); ++i ) {
bytes[i] = r & 0xFF;
r >>= 8;
-if (!r) r = std::rand();
+if (!r) r = seed_.dist(seed_.engine);
Review comment:
Thinking about the original algorithm, this line means that if there is
a zero byte at the "end" of the random number, it will not be put into the UUID
and a new number will be generated instead. For example, if the `seed_.dist`
before the loop generated a 0, then only the first byte will be put into the
uuid and then immediately a new random number will be generated. I'm trying to
say that the random data in the UUID will be IMO somewhat biased against `\x00`
bytes.
Maybe best to use something like `std::independent_bits_engine` suggested in
the first answer on
https://stackoverflow.com/questions/25298585/efficiently-generating-random-bytes-of-data-in-c11-14
##
File path: cpp/src/uuid.cpp
##
@@ -70,11 +74,11 @@ uuid uuid::copy(const char* bytes) {
uuid uuid::random() {
uuid bytes;
-int r = std::rand();
+int r = seed_.dist(seed_.engine);
Review comment:
std::rand returns numbers from 0 to INT_MAX. You are changing the range
now to include negative numbers. Is it intentional? Does it matter? AFAIK it
does, a little, for the better.
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
-seed() {
+std::random_device device;
+std::mt19937 engine;
+std::uniform_int_distribution dist;
+seed():engine(device()), dist(INT_MIN, INT_MAX) {
Review comment:
```suggestion
std::mt19937 engine(std::random_device{}());
std::uniform_int_distribution dist(INT_MIN, INT_MAX);
seed() {
```
I did not try the above, so maybe I am doing something completely silly, but
to me, if that works, it is a better option. Initializing in the constructor
initializer list seems clumsy, in that you have to make sure the order of the
declared variables and the order in which they are initialized is the same.
The C++ version of `INT_MAX` seems to be
`std::numeric_limits::max()`. Probably not worth using, as it is
significantly longer string to type.
##
File path: cpp/src/uuid.cpp
##
@@ -42,15 +44,17 @@ namespace {
// Seed the random number generated once at startup.
struct seed {
Review comment:
I'd rename this struct. At this point it is not a seed, it is the
generator.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
