[jira] [Updated] (DISPATCH-2091) TCP adaptor does not close listener connection when RX window is full
[
https://issues.apache.org/jira/browse/DISPATCH-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles E. Rolke updated DISPATCH-2091:
---
Attachment: INTB-tcplog.conf
INTA-tcplog.conf
> TCP adaptor does not close listener connection when RX window is full
> -
>
> Key: DISPATCH-2091
> URL: https://issues.apache.org/jira/browse/DISPATCH-2091
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: Charles E. Rolke
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: INTA-tcplog.conf, INTB-tcplog.conf
>
>
> A two-router network has TCP Listener on A and TCP Connector on B.
> The test program is a iperf3 server and a client run with
> {code:java}
> iperf3 -c 127.0.0.1 -p 5202 -t 2
> {code}
> Iperf3 creates two connections. The low-volume connection closes OK. The
> high-volume connection receives a network FIN but never responds with FIN/ACK.
> TCP logging for the stuck connection shows that the RX windows is full. When
> proton signals that read data is available the adaptor ignores it. This
> probably interrupts the normal event sequence and a DISCONNECTED event never
> arrives.
> The event sequence is
> {code:java}
> 2021-04-28 17:13:48.502875 -0400 TCP_ADAPTOR (trace) [C3][L28]
> handle_incoming PNRC_READ for listener connection. read_closed:F,
> flow_enabled:T
> 2021-04-28 17:13:48.502896 -0400 TCP_ADAPTOR (debug) [C3]
> pn_raw_connection_take_read_buffers() took 16, freed 0
> 2021-04-28 17:13:48.502907 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 16 to
> pn_raw_connection_give_read_buffers()
> 2021-04-28 17:13:48.503126 -0400 TCP_ADAPTOR (trace) [C3][L28][D22]
> Continuing listener message with 8192 bytes
> 2021-04-28 17:13:48.503140 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_READ Read 8192 bytes. Total read 45482021 bytes
> 2021-04-28 17:13:48.503188 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_READ listener Event
> 2021-04-28 17:13:48.503210 -0400 TCP_ADAPTOR (trace) [C3][L28]
> handle_incoming PNRC_READ for listener connection. read_closed:F,
> flow_enabled:T
> 2021-04-28 17:13:48.503229 -0400 TCP_ADAPTOR (trace) [C3] TCP RX window
> CLOSED: bytes in=45488165 unacked=1460232
> 2021-04-28 17:13:48.503244 -0400 TCP_ADAPTOR (debug) [C3]
> pn_raw_connection_take_read_buffers() took 12, freed 0
> 2021-04-28 17:13:48.503259 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 12 to
> pn_raw_connection_give_read_buffers()
> 2021-04-28 17:13:48.503316 -0400 TCP_ADAPTOR (debug) [C3] qdr_tcp_activate:
> call pn_raw_connection_wake()
> 2021-04-28 17:13:48.503393 -0400 TCP_ADAPTOR (trace) [C3][L28][D22]
> Continuing listener message with 6144 bytes
> 2021-04-28 17:13:48.503411 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_READ Read 6144 bytes. Total read 45488165 bytes
> 2021-04-28 17:13:48.503423 -0400 TCP_ADAPTOR (debug) [C3][L28] qdr_tcp_push
> 2021-04-28 17:13:48.503433 -0400 TCP_ADAPTOR (debug) [C3][L27][D25]
> qdr_tcp_deliver Delivery event
> 2021-04-28 17:13:48.503445 -0400 TCP_ADAPTOR (info) [C3] EOS
> 2021-04-28 17:13:48.503458 -0400 TCP_ADAPTOR (debug) [C3] handle_outgoing
> calling pn_raw_connection_write_close(). rcv_complete:T, send_complete:T
> 2021-04-28 17:13:48.503521 -0400 TCP_ADAPTOR (debug) [C3][L28] qdr_tcp_offer:
> NOOP
> 2021-04-28 17:13:48.503544 -0400 TCP_ADAPTOR (debug) [C3][L28]
> qdr_tcp_get_credit: NOOP
> 2021-04-28 17:13:48.503565 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_WAKE listener
> 2021-04-28 17:13:48.503670 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_CLOSED_WRITE listener
> 2021-04-28 17:13:48.503712 -0400 TCP_ADAPTOR (debug) [C3] qdr_tcp_activate:
> call pn_raw_connection_wake()
> 2021-04-28 17:13:48.503752 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_WAKE listener
> 2021-04-28 17:13:48.503830 -0400 TCP_ADAPTOR (debug) [C3][L28][D22]
> qdr_tcp_delivery_update: disp: 38, settled: false
> 2021-04-28 17:13:48.503852 -0400 TCP_ADAPTOR (debug) [C3][L28][D22]
> qdr_tcp_delivery_update: disp: 38, settled: false
> 2021-04-28 17:13:48.503868 -0400 TCP_ADAPTOR (debug) [C3][L28]
> qdr_tcp_get_credit: NOOP
> 2021-04-28 17:13:48.503932 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_READ listener Event
> 2021-04-28 17:13:48.503942 -0400 TCP_ADAPTOR (trace) [C3][L28]
> handle_incoming PNRC_READ for listener connection. read_closed:F,
> flow_enabled:T
> 2021-04-28 17:13:48.503950 -0400 TCP_ADAPTOR (debug) [C3]
> pn_raw_connection_take_read_buffers() took 0, freed 0
> 2021-04-28 17:13:48.503957 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 0 to
> pn_raw_connection_give_read_buffers()
> 2021-04-28 17:13:48.503965 -0400 TCP_ADAPTOR (debug) [C3]
> PN_RAW_CONNECTION_READ Read 0 bytes. Total read 45488165 bytes
> 2021-04-28
[jira] [Created] (DISPATCH-2091) TCP adaptor does not close listener connection when RX window is full
Charles E. Rolke created DISPATCH-2091:
--
Summary: TCP adaptor does not close listener connection when RX
window is full
Key: DISPATCH-2091
URL: https://issues.apache.org/jira/browse/DISPATCH-2091
Project: Qpid Dispatch
Issue Type: Bug
Components: Protocol Adaptors
Reporter: Charles E. Rolke
Fix For: 1.16.0
A two-router network has TCP Listener on A and TCP Connector on B.
The test program is a iperf3 server and a client run with
{code:java}
iperf3 -c 127.0.0.1 -p 5202 -t 2
{code}
Iperf3 creates two connections. The low-volume connection closes OK. The
high-volume connection receives a network FIN but never responds with FIN/ACK.
TCP logging for the stuck connection shows that the RX windows is full. When
proton signals that read data is available the adaptor ignores it. This
probably interrupts the normal event sequence and a DISCONNECTED event never
arrives.
The event sequence is
{code:java}
2021-04-28 17:13:48.502875 -0400 TCP_ADAPTOR (trace) [C3][L28] handle_incoming
PNRC_READ for listener connection. read_closed:F, flow_enabled:T
2021-04-28 17:13:48.502896 -0400 TCP_ADAPTOR (debug) [C3]
pn_raw_connection_take_read_buffers() took 16, freed 0
2021-04-28 17:13:48.502907 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 16 to
pn_raw_connection_give_read_buffers()
2021-04-28 17:13:48.503126 -0400 TCP_ADAPTOR (trace) [C3][L28][D22] Continuing
listener message with 8192 bytes
2021-04-28 17:13:48.503140 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_READ Read 8192 bytes. Total read 45482021 bytes
2021-04-28 17:13:48.503188 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_READ listener Event
2021-04-28 17:13:48.503210 -0400 TCP_ADAPTOR (trace) [C3][L28] handle_incoming
PNRC_READ for listener connection. read_closed:F, flow_enabled:T
2021-04-28 17:13:48.503229 -0400 TCP_ADAPTOR (trace) [C3] TCP RX window CLOSED:
bytes in=45488165 unacked=1460232
2021-04-28 17:13:48.503244 -0400 TCP_ADAPTOR (debug) [C3]
pn_raw_connection_take_read_buffers() took 12, freed 0
2021-04-28 17:13:48.503259 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 12 to
pn_raw_connection_give_read_buffers()
2021-04-28 17:13:48.503316 -0400 TCP_ADAPTOR (debug) [C3] qdr_tcp_activate:
call pn_raw_connection_wake()
2021-04-28 17:13:48.503393 -0400 TCP_ADAPTOR (trace) [C3][L28][D22] Continuing
listener message with 6144 bytes
2021-04-28 17:13:48.503411 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_READ Read 6144 bytes. Total read 45488165 bytes
2021-04-28 17:13:48.503423 -0400 TCP_ADAPTOR (debug) [C3][L28] qdr_tcp_push
2021-04-28 17:13:48.503433 -0400 TCP_ADAPTOR (debug) [C3][L27][D25]
qdr_tcp_deliver Delivery event
2021-04-28 17:13:48.503445 -0400 TCP_ADAPTOR (info) [C3] EOS
2021-04-28 17:13:48.503458 -0400 TCP_ADAPTOR (debug) [C3] handle_outgoing
calling pn_raw_connection_write_close(). rcv_complete:T, send_complete:T
2021-04-28 17:13:48.503521 -0400 TCP_ADAPTOR (debug) [C3][L28] qdr_tcp_offer:
NOOP
2021-04-28 17:13:48.503544 -0400 TCP_ADAPTOR (debug) [C3][L28]
qdr_tcp_get_credit: NOOP
2021-04-28 17:13:48.503565 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_WAKE listener
2021-04-28 17:13:48.503670 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_CLOSED_WRITE listener
2021-04-28 17:13:48.503712 -0400 TCP_ADAPTOR (debug) [C3] qdr_tcp_activate:
call pn_raw_connection_wake()
2021-04-28 17:13:48.503752 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_WAKE listener
2021-04-28 17:13:48.503830 -0400 TCP_ADAPTOR (debug) [C3][L28][D22]
qdr_tcp_delivery_update: disp: 38, settled: false
2021-04-28 17:13:48.503852 -0400 TCP_ADAPTOR (debug) [C3][L28][D22]
qdr_tcp_delivery_update: disp: 38, settled: false
2021-04-28 17:13:48.503868 -0400 TCP_ADAPTOR (debug) [C3][L28]
qdr_tcp_get_credit: NOOP
2021-04-28 17:13:48.503932 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_READ listener Event
2021-04-28 17:13:48.503942 -0400 TCP_ADAPTOR (trace) [C3][L28] handle_incoming
PNRC_READ for listener connection. read_closed:F, flow_enabled:T
2021-04-28 17:13:48.503950 -0400 TCP_ADAPTOR (debug) [C3]
pn_raw_connection_take_read_buffers() took 0, freed 0
2021-04-28 17:13:48.503957 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 0 to
pn_raw_connection_give_read_buffers()
2021-04-28 17:13:48.503965 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_READ Read 0 bytes. Total read 45488165 bytes
2021-04-28 17:13:48.503973 -0400 TCP_ADAPTOR (debug) [C3]
PN_RAW_CONNECTION_NEED_READ_BUFFERS listener
2021-04-28 17:13:48.503981 -0400 TCP_ADAPTOR (debug) [C3][L28] Granting 0 to
pn_raw_connection_give_read_buffers()
2021-04-28 17:13:48.503988 -0400 TCP_ADAPTOR (trace) [C3][L28] handle_incoming
PNRC_NEED_READ_BUFFERS for listener connection. read_closed:F, flow_enabled:T
2021-04-28 17:13:48.503996 -0400 TCP_ADAPTOR (debug) [C3]
pn_raw_connection_take_read_buffers() took 0, freed 0
2021-04-28
[jira] [Resolved] (DISPATCH-2082) Leak of qd_delivery_state_t in system_tests_http1_over_tcp
[
https://issues.apache.org/jira/browse/DISPATCH-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-2082.
-
Fix Version/s: 1.17.0
Assignee: Ganesh Murthy
Resolution: Fixed
> Leak of qd_delivery_state_t in system_tests_http1_over_tcp
> --
>
> Key: DISPATCH-2082
> URL: https://issues.apache.org/jira/browse/DISPATCH-2082
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.17.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/501211928#L11775
> This is PR build for pool poisoning, but the issue should be in no way
> related to that.
> {noformat}
> 71: Router INT.A debug dump file:
> 71:
> 71: alloc.c: Items of type 'qd_buffer_t' remain allocated at shutdown: 17
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_content_t' remain allocated at
> shutdown: 2 (SUPPRESSED)
> 71: alloc.c: Items of type 'qdr_delivery_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_delivery_state_t' remain allocated at
> shutdown: 1
> 71: Leak: 2021-04-26 20:06:52.908660 + type: qd_delivery_state_t address:
> 0x6127b9d0
> 71: qdrouterd(backtrace+0x5b) [0x45356b]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_alloc+0xa68)
> [0x7f38cf658ee8]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_delivery_state+0x28)
> [0x7f38cf69ad48]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x2f6248)
> [0x7f38cf644248]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x525402)
> [0x7f38cf873402]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x51ede0)
> [0x7f38cf86cde0]
> 71: /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f38cf2c5609]
> 71: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f38ceaf0293]
> {noformat}
> {noformat}
> 71: ==
> 71: ERROR: tearDownClass
> (system_tests_http1_over_tcp.Http1OverTcpOneRouterTest)
> 71: --
> 71: Traceback (most recent call last):
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 865, in tearDownClass
> 71: cls.tester.teardown()
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 808, in teardown
> 71: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 71: RuntimeError: Errors during teardown:
> 71:
> 71: Process 18806 error: exit code -6, expected 0
> 71: qdrouterd -c INT.A.conf -I /home/travis/build/apache/qpid-dispatch/python
> 71:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_http1_over_tcp/Http1OverTcpOneRouterTest/setUpClass/INT.A-4.cmd
> 71:
> 71: ERROR: Aborted due to unexpected alloc pool leak of type
> 'qd_delivery_state_t'
> 71:
> 71:
> 71: --
> 71: Ran 12 tests in 32.652s
> 71:
> 71: FAILED (errors=1)
> 71/74 Test #71: system_tests_http1_over_tcp ...***Failed
> 32.78 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2082) Leak of qd_delivery_state_t in system_tests_http1_over_tcp
[
https://issues.apache.org/jira/browse/DISPATCH-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335000#comment-17335000
]
ASF GitHub Bot commented on DISPATCH-2082:
--
asfgit closed pull request #1175:
URL: https://github.com/apache/qpid-dispatch/pull/1175
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Leak of qd_delivery_state_t in system_tests_http1_over_tcp
> --
>
> Key: DISPATCH-2082
> URL: https://issues.apache.org/jira/browse/DISPATCH-2082
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/501211928#L11775
> This is PR build for pool poisoning, but the issue should be in no way
> related to that.
> {noformat}
> 71: Router INT.A debug dump file:
> 71:
> 71: alloc.c: Items of type 'qd_buffer_t' remain allocated at shutdown: 17
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_content_t' remain allocated at
> shutdown: 2 (SUPPRESSED)
> 71: alloc.c: Items of type 'qdr_delivery_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_delivery_state_t' remain allocated at
> shutdown: 1
> 71: Leak: 2021-04-26 20:06:52.908660 + type: qd_delivery_state_t address:
> 0x6127b9d0
> 71: qdrouterd(backtrace+0x5b) [0x45356b]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_alloc+0xa68)
> [0x7f38cf658ee8]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_delivery_state+0x28)
> [0x7f38cf69ad48]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x2f6248)
> [0x7f38cf644248]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x525402)
> [0x7f38cf873402]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x51ede0)
> [0x7f38cf86cde0]
> 71: /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f38cf2c5609]
> 71: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f38ceaf0293]
> {noformat}
> {noformat}
> 71: ==
> 71: ERROR: tearDownClass
> (system_tests_http1_over_tcp.Http1OverTcpOneRouterTest)
> 71: --
> 71: Traceback (most recent call last):
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 865, in tearDownClass
> 71: cls.tester.teardown()
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 808, in teardown
> 71: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 71: RuntimeError: Errors during teardown:
> 71:
> 71: Process 18806 error: exit code -6, expected 0
> 71: qdrouterd -c INT.A.conf -I /home/travis/build/apache/qpid-dispatch/python
> 71:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_http1_over_tcp/Http1OverTcpOneRouterTest/setUpClass/INT.A-4.cmd
> 71:
> 71: ERROR: Aborted due to unexpected alloc pool leak of type
> 'qd_delivery_state_t'
> 71:
> 71:
> 71: --
> 71: Ran 12 tests in 32.652s
> 71:
> 71: FAILED (errors=1)
> 71/74 Test #71: system_tests_http1_over_tcp ...***Failed
> 32.78 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2082) Leak of qd_delivery_state_t in system_tests_http1_over_tcp
[
https://issues.apache.org/jira/browse/DISPATCH-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334999#comment-17334999
]
ASF subversion and git services commented on DISPATCH-2082:
---
Commit 84186ce0084f044a1e43689c4c0b648838305dbc in qpid-dispatch's branch
refs/heads/main from Ganesh Murthy
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=84186ce ]
DISPATCH-2082: Added qd_delivery_state_t to leaking_types arrary. This closes
#1175.
> Leak of qd_delivery_state_t in system_tests_http1_over_tcp
> --
>
> Key: DISPATCH-2082
> URL: https://issues.apache.org/jira/browse/DISPATCH-2082
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/501211928#L11775
> This is PR build for pool poisoning, but the issue should be in no way
> related to that.
> {noformat}
> 71: Router INT.A debug dump file:
> 71:
> 71: alloc.c: Items of type 'qd_buffer_t' remain allocated at shutdown: 17
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_content_t' remain allocated at
> shutdown: 2 (SUPPRESSED)
> 71: alloc.c: Items of type 'qdr_delivery_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_delivery_state_t' remain allocated at
> shutdown: 1
> 71: Leak: 2021-04-26 20:06:52.908660 + type: qd_delivery_state_t address:
> 0x6127b9d0
> 71: qdrouterd(backtrace+0x5b) [0x45356b]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_alloc+0xa68)
> [0x7f38cf658ee8]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_delivery_state+0x28)
> [0x7f38cf69ad48]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x2f6248)
> [0x7f38cf644248]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x525402)
> [0x7f38cf873402]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x51ede0)
> [0x7f38cf86cde0]
> 71: /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f38cf2c5609]
> 71: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f38ceaf0293]
> {noformat}
> {noformat}
> 71: ==
> 71: ERROR: tearDownClass
> (system_tests_http1_over_tcp.Http1OverTcpOneRouterTest)
> 71: --
> 71: Traceback (most recent call last):
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 865, in tearDownClass
> 71: cls.tester.teardown()
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 808, in teardown
> 71: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 71: RuntimeError: Errors during teardown:
> 71:
> 71: Process 18806 error: exit code -6, expected 0
> 71: qdrouterd -c INT.A.conf -I /home/travis/build/apache/qpid-dispatch/python
> 71:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_http1_over_tcp/Http1OverTcpOneRouterTest/setUpClass/INT.A-4.cmd
> 71:
> 71: ERROR: Aborted due to unexpected alloc pool leak of type
> 'qd_delivery_state_t'
> 71:
> 71:
> 71: --
> 71: Ran 12 tests in 32.652s
> 71:
> 71: FAILED (errors=1)
> 71/74 Test #71: system_tests_http1_over_tcp ...***Failed
> 32.78 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #1175: DISPATCH-2082: Added qd_delivery_state_t to leaking_types arrary
asfgit closed pull request #1175: URL: https://github.com/apache/qpid-dispatch/pull/1175 -- 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. 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-2082) Leak of qd_delivery_state_t in system_tests_http1_over_tcp
[
https://issues.apache.org/jira/browse/DISPATCH-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334988#comment-17334988
]
ASF GitHub Bot commented on DISPATCH-2082:
--
ganeshmurthy opened a new pull request #1175:
URL: https://github.com/apache/qpid-dispatch/pull/1175
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Leak of qd_delivery_state_t in system_tests_http1_over_tcp
> --
>
> Key: DISPATCH-2082
> URL: https://issues.apache.org/jira/browse/DISPATCH-2082
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/501211928#L11775
> This is PR build for pool poisoning, but the issue should be in no way
> related to that.
> {noformat}
> 71: Router INT.A debug dump file:
> 71:
> 71: alloc.c: Items of type 'qd_buffer_t' remain allocated at shutdown: 17
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_message_content_t' remain allocated at
> shutdown: 2 (SUPPRESSED)
> 71: alloc.c: Items of type 'qdr_delivery_t' remain allocated at shutdown: 2
> (SUPPRESSED)
> 71: alloc.c: Items of type 'qd_delivery_state_t' remain allocated at
> shutdown: 1
> 71: Leak: 2021-04-26 20:06:52.908660 + type: qd_delivery_state_t address:
> 0x6127b9d0
> 71: qdrouterd(backtrace+0x5b) [0x45356b]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_alloc+0xa68)
> [0x7f38cf658ee8]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(qd_delivery_state+0x28)
> [0x7f38cf69ad48]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x2f6248)
> [0x7f38cf644248]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x525402)
> [0x7f38cf873402]
> 71:
> /home/travis/build/apache/qpid-dispatch/build/src/libqpid-dispatch.so(+0x51ede0)
> [0x7f38cf86cde0]
> 71: /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f38cf2c5609]
> 71: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f38ceaf0293]
> {noformat}
> {noformat}
> 71: ==
> 71: ERROR: tearDownClass
> (system_tests_http1_over_tcp.Http1OverTcpOneRouterTest)
> 71: --
> 71: Traceback (most recent call last):
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 865, in tearDownClass
> 71: cls.tester.teardown()
> 71: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 808, in teardown
> 71: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 71: RuntimeError: Errors during teardown:
> 71:
> 71: Process 18806 error: exit code -6, expected 0
> 71: qdrouterd -c INT.A.conf -I /home/travis/build/apache/qpid-dispatch/python
> 71:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_http1_over_tcp/Http1OverTcpOneRouterTest/setUpClass/INT.A-4.cmd
> 71:
> 71: ERROR: Aborted due to unexpected alloc pool leak of type
> 'qd_delivery_state_t'
> 71:
> 71:
> 71: --
> 71: Ran 12 tests in 32.652s
> 71:
> 71: FAILED (errors=1)
> 71/74 Test #71: system_tests_http1_over_tcp ...***Failed
> 32.78 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy opened a new pull request #1175: DISPATCH-2082: Added qd_delivery_state_t to leaking_types arrary
ganeshmurthy opened a new pull request #1175: URL: https://github.com/apache/qpid-dispatch/pull/1175 -- 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. 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-2055) AddressSanitizer: heap-use-after-free in write_log during system_tests_qdmanage
[
https://issues.apache.org/jira/browse/DISPATCH-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334976#comment-17334976
]
ASF GitHub Bot commented on DISPATCH-2055:
--
ganeshmurthy commented on a change in pull request #1146:
URL: https://github.com/apache/qpid-dispatch/pull/1146#discussion_r622495968
##
File path: src/log.c
##
@@ -425,7 +434,6 @@ void qd_vlog_impl(qd_log_source_t *source, qd_log_level_t
level, bool check_leve
}
// Bounded buffer of log entries, keep most recent.
-sys_mutex_lock(log_lock);
qd_log_entry_t *entry = new_qd_log_entry_t();
DEQ_ITEM_INIT(entry);
entry->module = source->module;
Review comment:
I am proposing that we just move the lock back to where it originally
was, like just before this line - qd_log_entry_t *entry = new_qd_log_entry_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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> AddressSanitizer: heap-use-after-free in write_log during
> system_tests_qdmanage
> ---
>
> Key: DISPATCH-2055
> URL: https://issues.apache.org/jira/browse/DISPATCH-2055
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.17.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/498853046#L5728
> {noformat}
> 29: Process 13857 error: exit code 1, expected -1
> 29: qdrouterd -c test_router_1.conf -I
> /home/travis/build/apache/qpid-dispatch/python
> 29:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_qdmanage/QdmanageTest/setUpClass/test_router_1-2.cmd
> 29:
> 29: =
> 29: ==13857==ERROR: AddressSanitizer: heap-use-after-free on address
> 0xaca04ba8 at pc 0xb1f23f34 bp 0xa5cf2770 sp 0xa5cf2768
> 29: READ of size 8 at 0xaca04ba8 thread T2
> 29: #0 0xb1f23f30 in write_log
> /home/travis/build/apache/qpid-dispatch/src/log.c:343:22
> 29: #1 0xb1f23f30 in qd_vlog_impl
> /home/travis/build/apache/qpid-dispatch/src/log.c:437:5
> 29: #2 0xb1f24d44 in qd_log_impl
> /home/travis/build/apache/qpid-dispatch/src/log.c:456:3
> 29: #3 0xb1b482c8 in pni_tracer_to_log_sink
> /home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/core/transport.c:2874:3
> 29:
> 29: 0xaca04ba8 is located 24 bytes inside of 48-byte region
> [0xaca04b90,0xaca04bc0)
> 29: freed by thread T3 here:
> 29: #0 0x48f30c in free
> (/home/travis/build/apache/qpid-dispatch/build/router/qdrouterd+0x48f30c)
> 29: #1 0xb1f27c64 in qd_log_entity
> /home/travis/build/apache/qpid-dispatch/src/log.c:555:17
> 29: #2 0xacf09ff4 (/lib/aarch64-linux-gnu/libffi.so.7+0x5ff4)
> 29: #3 0xacf097c8 (/lib/aarch64-linux-gnu/libffi.so.7+0x57c8)
> 29: #4 0xacddfd20 in _ctypes_callproc
> (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-aarch64-linux-gnu.so+0xfd20)
> 29: #5 0xacde0334
> (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-aarch64-linux-gnu.so+0x10334)
> 29: #6 0xb17dc604 in _PyObject_MakeTpCall
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x299604)
> 29: #7 0xb15b6698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73698)
> 29: #8 0xb15bd888 in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7a888)
> 29: #9 0xb15c1698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7e698)
> 29: #10 0xb17dc8a0
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x2998a0)
> 29: #11 0xb15b6624
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73624)
> 29: #12 0xb15bd888 in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7a888)
> 29: #13 0xb15c1698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7e698)
> 29: #14 0xb17dc8a0
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x2998a0)
> 29: #15 0xb15b6624
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73624)
> 29: #16 0xb15bb3bc in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x783bc)
> 29: #17 0xb15c1698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7e698)
> 29: #18 0xb15b6624
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73624)
> 29: #19 0xb15b75a0 in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x745a0)
> 29: #20 0xb1702958 in _PyEval_EvalCodeWithName
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x1bf958)
> 29: #21
[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #1146: DISPATCH-2055: Eliminated log_lock and used the log_source_lock instead
ganeshmurthy commented on a change in pull request #1146: URL: https://github.com/apache/qpid-dispatch/pull/1146#discussion_r622495968 ## File path: src/log.c ## @@ -425,7 +434,6 @@ void qd_vlog_impl(qd_log_source_t *source, qd_log_level_t level, bool check_leve } // Bounded buffer of log entries, keep most recent. -sys_mutex_lock(log_lock); qd_log_entry_t *entry = new_qd_log_entry_t(); DEQ_ITEM_INIT(entry); entry->module = source->module; Review comment: I am proposing that we just move the lock back to where it originally was, like just before this line - qd_log_entry_t *entry = new_qd_log_entry_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. 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-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334971#comment-17334971
]
ASF GitHub Bot commented on DISPATCH-2088:
--
mgoulish commented on pull request #1174:
URL: https://github.com/apache/qpid-dispatch/pull/1174#issuecomment-828736055
DEADBUG
Before this patch I had failure rate of 11.8%
Now I have zero failures in 100 tries. Odd of happening randomly are 1 in
300,000.
Ship 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] mgoulish commented on pull request #1174: DISPATCH-2088: Free message_stream_data objects on connection thread
mgoulish commented on pull request #1174: URL: https://github.com/apache/qpid-dispatch/pull/1174#issuecomment-828736055 DEADBUG Before this patch I had failure rate of 11.8% Now I have zero failures in 100 tries. Odd of happening randomly are 1 in 300,000. Ship 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. 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-2055) AddressSanitizer: heap-use-after-free in write_log during system_tests_qdmanage
[
https://issues.apache.org/jira/browse/DISPATCH-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334969#comment-17334969
]
ASF GitHub Bot commented on DISPATCH-2055:
--
kgiusti commented on a change in pull request #1146:
URL: https://github.com/apache/qpid-dispatch/pull/1146#discussion_r622485407
##
File path: src/log.c
##
@@ -271,7 +280,7 @@ static const char* level_name(int level) {
static const char *SEPARATORS=", ;:";
/// Calculate the bit mask for a log enable string. Return -1 and set qd_error
on error.
-static int enable_mask(const char *enable_) {
+static int enable_mask(const char *enable_, bool log_error) {
Review comment:
This also appears to only be called with log_error=false, which makes
the log_error parameter & logic not necessary.
##
File path: src/log.c
##
@@ -525,71 +538,143 @@ void qd_log_finalize(void) {
log_sink_free_lh(DEQ_HEAD(sink_list));
}
-qd_error_t qd_log_entity(qd_entity_t *entity) {
-
+qd_error_t qd_log_entity(qd_entity_t *entity)
+{
qd_error_clear();
-//Obtain the log_source_lock global lock
-sys_mutex_lock(log_source_lock);
-
char* module = 0;
-char *output = 0;
+char *outputFile = 0;
char *enable = 0;
+int include_timestamp = 0;
+int include_source = 0;
+
+bool has_enable = false;
+bool has_output_file = false;
+bool has_include_timestamp = false;
+bool has_include_source = false;
+bool is_sink_syslog = false;
bool trace_enabled = false;
+bool error_in_output = false;
+bool error_in_enable = false;
do {
-
+//
+// A module attribute MUST be specified for a log entity.
+// Every other attribute is optional.
+//
module = qd_entity_get_string(entity, "module");
+
+//
+// If the module is not specified, there is nothing to do, just log an
+// error and break out of this do loop.
+//
QD_ERROR_BREAK();
Review comment:
IIRC these QD_ERROR_BREAK's force a jump to the end of the while (0)
loop.
At the end of the while (0) loop there is a mutex unlock call, which will be
unlocking a mutex which is not locked.
##
File path: src/log.c
##
@@ -222,27 +222,36 @@ static level_t levels[] = {
LEVEL("critical", QD_LOG_CRITICAL, LOG_CRIT)
};
+static const level_t invalid_level = {"invalid", -2, -2, 0};
+
static char level_names[TEXT_MAX] = {0}; /* Set up in qd_log_initialize */
/// Return NULL and set qd_error if not a valid bit.
-static const level_t* level_for_bit(int bit) {
+static const level_t* level_for_bit(int bit, bool log_error) {
Review comment:
IIUC this level_for_bit is only called by write_log(), which passes
log_error=false.
So why add the bool at all? Simply remove the qd_error since it will never
be called.
##
File path: src/log.c
##
@@ -222,27 +222,36 @@ static level_t levels[] = {
LEVEL("critical", QD_LOG_CRITICAL, LOG_CRIT)
};
+static const level_t invalid_level = {"invalid", -2, -2, 0};
+
static char level_names[TEXT_MAX] = {0}; /* Set up in qd_log_initialize */
/// Return NULL and set qd_error if not a valid bit.
-static const level_t* level_for_bit(int bit) {
+static const level_t* level_for_bit(int bit, bool log_error) {
level_index_t i = 0;
while (i < N_LEVELS && levels[i].bit != bit) ++i;
if (i == N_LEVELS) {
-qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.", bit);
-return NULL;
+if (log_error)
+qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.",
bit);
+return _level;
}
return [i];
}
+static bool is_log_level_invalid(const level_t *level)
+{
+return ! strcmp(level->name, "invalid");
+}
+
/// Return NULL and set qd_error if not a valid level.
-static const level_t* level_for_name(const char *name, int len) {
+static const level_t* level_for_name(const char *name, int len, bool
log_error) {
Review comment:
same here, log_error is essentially unused.
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> AddressSanitizer: heap-use-after-free in write_log during
> system_tests_qdmanage
> ---
>
> Key: DISPATCH-2055
> URL: https://issues.apache.org/jira/browse/DISPATCH-2055
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.17.0
>
>
>
[GitHub] [qpid-dispatch] kgiusti commented on a change in pull request #1146: DISPATCH-2055: Eliminated log_lock and used the log_source_lock instead
kgiusti commented on a change in pull request #1146:
URL: https://github.com/apache/qpid-dispatch/pull/1146#discussion_r622485407
##
File path: src/log.c
##
@@ -271,7 +280,7 @@ static const char* level_name(int level) {
static const char *SEPARATORS=", ;:";
/// Calculate the bit mask for a log enable string. Return -1 and set qd_error
on error.
-static int enable_mask(const char *enable_) {
+static int enable_mask(const char *enable_, bool log_error) {
Review comment:
This also appears to only be called with log_error=false, which makes
the log_error parameter & logic not necessary.
##
File path: src/log.c
##
@@ -525,71 +538,143 @@ void qd_log_finalize(void) {
log_sink_free_lh(DEQ_HEAD(sink_list));
}
-qd_error_t qd_log_entity(qd_entity_t *entity) {
-
+qd_error_t qd_log_entity(qd_entity_t *entity)
+{
qd_error_clear();
-//Obtain the log_source_lock global lock
-sys_mutex_lock(log_source_lock);
-
char* module = 0;
-char *output = 0;
+char *outputFile = 0;
char *enable = 0;
+int include_timestamp = 0;
+int include_source = 0;
+
+bool has_enable = false;
+bool has_output_file = false;
+bool has_include_timestamp = false;
+bool has_include_source = false;
+bool is_sink_syslog = false;
bool trace_enabled = false;
+bool error_in_output = false;
+bool error_in_enable = false;
do {
-
+//
+// A module attribute MUST be specified for a log entity.
+// Every other attribute is optional.
+//
module = qd_entity_get_string(entity, "module");
+
+//
+// If the module is not specified, there is nothing to do, just log an
+// error and break out of this do loop.
+//
QD_ERROR_BREAK();
Review comment:
IIRC these QD_ERROR_BREAK's force a jump to the end of the while (0)
loop.
At the end of the while (0) loop there is a mutex unlock call, which will be
unlocking a mutex which is not locked.
##
File path: src/log.c
##
@@ -222,27 +222,36 @@ static level_t levels[] = {
LEVEL("critical", QD_LOG_CRITICAL, LOG_CRIT)
};
+static const level_t invalid_level = {"invalid", -2, -2, 0};
+
static char level_names[TEXT_MAX] = {0}; /* Set up in qd_log_initialize */
/// Return NULL and set qd_error if not a valid bit.
-static const level_t* level_for_bit(int bit) {
+static const level_t* level_for_bit(int bit, bool log_error) {
Review comment:
IIUC this level_for_bit is only called by write_log(), which passes
log_error=false.
So why add the bool at all? Simply remove the qd_error since it will never
be called.
##
File path: src/log.c
##
@@ -222,27 +222,36 @@ static level_t levels[] = {
LEVEL("critical", QD_LOG_CRITICAL, LOG_CRIT)
};
+static const level_t invalid_level = {"invalid", -2, -2, 0};
+
static char level_names[TEXT_MAX] = {0}; /* Set up in qd_log_initialize */
/// Return NULL and set qd_error if not a valid bit.
-static const level_t* level_for_bit(int bit) {
+static const level_t* level_for_bit(int bit, bool log_error) {
level_index_t i = 0;
while (i < N_LEVELS && levels[i].bit != bit) ++i;
if (i == N_LEVELS) {
-qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.", bit);
-return NULL;
+if (log_error)
+qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.",
bit);
+return _level;
}
return [i];
}
+static bool is_log_level_invalid(const level_t *level)
+{
+return ! strcmp(level->name, "invalid");
+}
+
/// Return NULL and set qd_error if not a valid level.
-static const level_t* level_for_name(const char *name, int len) {
+static const level_t* level_for_name(const char *name, int len, bool
log_error) {
Review comment:
same here, log_error is essentially unused.
--
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.
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-2055) AddressSanitizer: heap-use-after-free in write_log during system_tests_qdmanage
[
https://issues.apache.org/jira/browse/DISPATCH-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334967#comment-17334967
]
ASF GitHub Bot commented on DISPATCH-2055:
--
ChugR commented on a change in pull request #1146:
URL: https://github.com/apache/qpid-dispatch/pull/1146#discussion_r622470098
##
File path: src/log.c
##
@@ -222,27 +222,36 @@ static level_t levels[] = {
LEVEL("critical", QD_LOG_CRITICAL, LOG_CRIT)
};
+static const level_t invalid_level = {"invalid", -2, -2, 0};
+
static char level_names[TEXT_MAX] = {0}; /* Set up in qd_log_initialize */
/// Return NULL and set qd_error if not a valid bit.
-static const level_t* level_for_bit(int bit) {
+static const level_t* level_for_bit(int bit, bool log_error) {
level_index_t i = 0;
while (i < N_LEVELS && levels[i].bit != bit) ++i;
if (i == N_LEVELS) {
-qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.", bit);
-return NULL;
+if (log_error)
+qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.",
bit);
+return _level;
}
return [i];
}
+static bool is_log_level_invalid(const level_t *level)
+{
+return ! strcmp(level->name, "invalid");
Review comment:
A better (faster) comparison might be
level->bit != -2
Then inline it.
##
File path: src/log.c
##
@@ -425,7 +434,6 @@ void qd_vlog_impl(qd_log_source_t *source, qd_log_level_t
level, bool check_leve
}
// Bounded buffer of log entries, keep most recent.
-sys_mutex_lock(log_lock);
qd_log_entry_t *entry = new_qd_log_entry_t();
DEQ_ITEM_INIT(entry);
entry->module = source->module;
Review comment:
source->module is a char*. Copying the pointer to entry leaves it
vulnerable to deletion as described in the comment at line 446. This string
should be copied into entry the same way that entry->file is strdup'd on line
441. Then the entry is not depending on source still existing the whole time
entry is in the entries list (line 542).
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> AddressSanitizer: heap-use-after-free in write_log during
> system_tests_qdmanage
> ---
>
> Key: DISPATCH-2055
> URL: https://issues.apache.org/jira/browse/DISPATCH-2055
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.17.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/498853046#L5728
> {noformat}
> 29: Process 13857 error: exit code 1, expected -1
> 29: qdrouterd -c test_router_1.conf -I
> /home/travis/build/apache/qpid-dispatch/python
> 29:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_qdmanage/QdmanageTest/setUpClass/test_router_1-2.cmd
> 29:
> 29: =
> 29: ==13857==ERROR: AddressSanitizer: heap-use-after-free on address
> 0xaca04ba8 at pc 0xb1f23f34 bp 0xa5cf2770 sp 0xa5cf2768
> 29: READ of size 8 at 0xaca04ba8 thread T2
> 29: #0 0xb1f23f30 in write_log
> /home/travis/build/apache/qpid-dispatch/src/log.c:343:22
> 29: #1 0xb1f23f30 in qd_vlog_impl
> /home/travis/build/apache/qpid-dispatch/src/log.c:437:5
> 29: #2 0xb1f24d44 in qd_log_impl
> /home/travis/build/apache/qpid-dispatch/src/log.c:456:3
> 29: #3 0xb1b482c8 in pni_tracer_to_log_sink
> /home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/core/transport.c:2874:3
> 29:
> 29: 0xaca04ba8 is located 24 bytes inside of 48-byte region
> [0xaca04b90,0xaca04bc0)
> 29: freed by thread T3 here:
> 29: #0 0x48f30c in free
> (/home/travis/build/apache/qpid-dispatch/build/router/qdrouterd+0x48f30c)
> 29: #1 0xb1f27c64 in qd_log_entity
> /home/travis/build/apache/qpid-dispatch/src/log.c:555:17
> 29: #2 0xacf09ff4 (/lib/aarch64-linux-gnu/libffi.so.7+0x5ff4)
> 29: #3 0xacf097c8 (/lib/aarch64-linux-gnu/libffi.so.7+0x57c8)
> 29: #4 0xacddfd20 in _ctypes_callproc
> (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-aarch64-linux-gnu.so+0xfd20)
> 29: #5 0xacde0334
> (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-aarch64-linux-gnu.so+0x10334)
> 29: #6 0xb17dc604 in _PyObject_MakeTpCall
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x299604)
> 29: #7 0xb15b6698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73698)
> 29: #8 0xb15bd888 in _PyEval_EvalFrameDefault
[GitHub] [qpid-dispatch] ChugR commented on a change in pull request #1146: DISPATCH-2055: Eliminated log_lock and used the log_source_lock instead
ChugR commented on a change in pull request #1146:
URL: https://github.com/apache/qpid-dispatch/pull/1146#discussion_r622470098
##
File path: src/log.c
##
@@ -222,27 +222,36 @@ static level_t levels[] = {
LEVEL("critical", QD_LOG_CRITICAL, LOG_CRIT)
};
+static const level_t invalid_level = {"invalid", -2, -2, 0};
+
static char level_names[TEXT_MAX] = {0}; /* Set up in qd_log_initialize */
/// Return NULL and set qd_error if not a valid bit.
-static const level_t* level_for_bit(int bit) {
+static const level_t* level_for_bit(int bit, bool log_error) {
level_index_t i = 0;
while (i < N_LEVELS && levels[i].bit != bit) ++i;
if (i == N_LEVELS) {
-qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.", bit);
-return NULL;
+if (log_error)
+qd_error(QD_ERROR_CONFIG, "'%d' is not a valid log level bit.",
bit);
+return _level;
}
return [i];
}
+static bool is_log_level_invalid(const level_t *level)
+{
+return ! strcmp(level->name, "invalid");
Review comment:
A better (faster) comparison might be
level->bit != -2
Then inline it.
##
File path: src/log.c
##
@@ -425,7 +434,6 @@ void qd_vlog_impl(qd_log_source_t *source, qd_log_level_t
level, bool check_leve
}
// Bounded buffer of log entries, keep most recent.
-sys_mutex_lock(log_lock);
qd_log_entry_t *entry = new_qd_log_entry_t();
DEQ_ITEM_INIT(entry);
entry->module = source->module;
Review comment:
source->module is a char*. Copying the pointer to entry leaves it
vulnerable to deletion as described in the comment at line 446. This string
should be copied into entry the same way that entry->file is strdup'd on line
441. Then the entry is not depending on source still existing the whole time
entry is in the entries list (line 542).
--
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.
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-dispatch] asfgit closed pull request #1171: NO-JIRA: extend test timeout for s390x platform
asfgit closed pull request #1171: URL: https://github.com/apache/qpid-dispatch/pull/1171 -- 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. 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] [Reopened] (DISPATCH-2028) Edge router system test is failing on RHEL8
[ https://issues.apache.org/jira/browse/DISPATCH-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reopened DISPATCH-2028: - > Edge router system test is failing on RHEL8 > --- > > Key: DISPATCH-2028 > URL: https://issues.apache.org/jira/browse/DISPATCH-2028 > Project: Qpid Dispatch > Issue Type: Test >Reporter: Fernando Giorgetti >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.16.0 > > Attachments: system_tests_edge_router.rhel8.log > > > Two edge router system tests are failing on RHEL8: > test_61_anon_sender_multicast_mobile_address_edge_to_interior > test_66_anon_sender_drop_rx_client_multicast_large_message > > Output for this particular ST is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] codecov-commenter commented on pull request #1173: NO-JIRA Update clang to 12 in Travis CI
codecov-commenter commented on pull request #1173: URL: https://github.com/apache/qpid-dispatch/pull/1173#issuecomment-828644313 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1173](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (d7f3681) into [main](https://codecov.io/gh/apache/qpid-dispatch/commit/d2f47a19077e604bce22513955dc9466192ca4ca?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (d2f47a1) will **increase** coverage by `0.03%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) ```diff @@Coverage Diff @@ ## main#1173 +/- ## == + Coverage 84.23% 84.26% +0.03% == Files 112 112 Lines 2766727667 == + Hits2330423314 +10 + Misses 4363 4353 -10 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.27% <0.00%> (-0.87%)` | :arrow_down: | | [src/router\_core/forwarder.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2ZvcndhcmRlci5j) | `92.64% <0.00%> (-0.40%)` | :arrow_down: | | [src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=) | `70.76% <0.00%> (+0.23%)` | :arrow_up: | | [src/adaptors/http1/http1\_server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX3NlcnZlci5j) | `84.88% <0.00%> (+0.29%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `89.53% <0.00%> (+0.29%)` | :arrow_up: | | [src/router\_core/delivery.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2RlbGl2ZXJ5LmM=) | `93.51% <0.00%> (+0.55%)` | :arrow_up: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1173/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `87.23% <0.00%> (+0.96%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=footer_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Last update [04c1001...d7f3681](https://codecov.io/gh/apache/qpid-dispatch/pull/1173?src=pr=lastupdated_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Read the [comment
[jira] [Commented] (PROTON-2095) Move away from SWIG to CFFI
[ https://issues.apache.org/jira/browse/PROTON-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334887#comment-17334887 ] Andrew Stitcher commented on PROTON-2095: - Jiri I see you've been working on this - would you like to have a chat about it - I've already put a few days of effort into it (maybe a year or more ago though). I'm not clear if your approach is similar to mine or not so I think it might be useful for us to go through the steps here. Andrew > Move away from SWIG to CFFI > --- > > Key: PROTON-2095 > URL: https://issues.apache.org/jira/browse/PROTON-2095 > Project: Qpid Proton > Issue Type: Wish > Components: python-binding >Affects Versions: proton-c-future, proton-c-0.29.0 >Reporter: Omer Katz >Priority: Major > Fix For: proton-c-future > > > SWIG is fine but we're not using it for anything other than exporting all of > proton-c's API as is. > Unfortunately SWIG only generates CPython extension bindings. This may be a > problem on PyPy where CPython extensions are either slow or simply won't > compile. > Unlike SWIG, CFFI is portable both on CPython and PyPy. > It also satisfies the same requirements as SWIG currently does. > In addition, calls to CFFI simply release the GIL which will help > parallelizing Python applications using threads. > By using CFFI we can also get rid of all of our setup.py code and simply use > it to build the extension. We will also no longer have problems building > wheels. > The newest version of CFFI supports pkg-config so we can use that to find > proton-c easily. > I'm willing to help with the refactor but I'll need a mentor since I'm not > familiar with the code base. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334886#comment-17334886
]
ASF GitHub Bot commented on DISPATCH-2088:
--
ChugR opened a new pull request #1174:
URL: https://github.com/apache/qpid-dispatch/pull/1174
and not on the core thread. Move flush_outgoing_bufs call to
handle_disconnected function.
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR opened a new pull request #1174: DISPATCH-2088: Free message_stream_data objects on connection thread
ChugR opened a new pull request #1174: URL: https://github.com/apache/qpid-dispatch/pull/1174 and not on the core thread. Move flush_outgoing_bufs call to handle_disconnected function. -- 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. 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-2055) AddressSanitizer: heap-use-after-free in write_log during system_tests_qdmanage
[ https://issues.apache.org/jira/browse/DISPATCH-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334879#comment-17334879 ] ASF GitHub Bot commented on DISPATCH-2055: -- codecov-commenter edited a comment on pull request #1146: URL: https://github.com/apache/qpid-dispatch/pull/1146#issuecomment-824404746 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1146](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (b5474ac) into [main](https://codecov.io/gh/apache/qpid-dispatch/commit/d2f47a19077e604bce22513955dc9466192ca4ca?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (d2f47a1) will **increase** coverage by `0.04%`. > The diff coverage is `92.75%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) ```diff @@Coverage Diff @@ ## main#1146 +/- ## == + Coverage 84.23% 84.27% +0.04% == Files 112 112 Lines 2766727697 +30 == + Hits2330423341 +37 + Misses 4363 4356 -7 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [src/log.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2xvZy5j) | `90.44% <92.75%> (-0.05%)` | :arrow_down: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.27% <0.00%> (-0.87%)` | :arrow_down: | | [src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=) | `70.29% <0.00%> (-0.24%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `92.76% <0.00%> (+0.09%)` | :arrow_up: | | [src/adaptors/http1/http1\_codec.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX2NvZGVjLmM=) | `85.28% <0.00%> (+0.12%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `89.53% <0.00%> (+0.29%)` | :arrow_up: | | [src/router\_core/delivery.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2RlbGl2ZXJ5LmM=) | `93.33% <0.00%> (+0.37%)` | :arrow_up: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `87.39% <0.00%> (+1.13%)` | :arrow_up: | | [src/router\_core/agent\_address.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2FkZHJlc3MuYw==) | `89.76% <0.00%> (+1.57%)` | :arrow_up: | -- [Continue to review full report at
[GitHub] [qpid-dispatch] codecov-commenter edited a comment on pull request #1146: DISPATCH-2055: Eliminated log_lock and used the log_source_lock instead
codecov-commenter edited a comment on pull request #1146: URL: https://github.com/apache/qpid-dispatch/pull/1146#issuecomment-824404746 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1146](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (b5474ac) into [main](https://codecov.io/gh/apache/qpid-dispatch/commit/d2f47a19077e604bce22513955dc9466192ca4ca?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (d2f47a1) will **increase** coverage by `0.04%`. > The diff coverage is `92.75%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) ```diff @@Coverage Diff @@ ## main#1146 +/- ## == + Coverage 84.23% 84.27% +0.04% == Files 112 112 Lines 2766727697 +30 == + Hits2330423341 +37 + Misses 4363 4356 -7 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [src/log.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2xvZy5j) | `90.44% <92.75%> (-0.05%)` | :arrow_down: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.27% <0.00%> (-0.87%)` | :arrow_down: | | [src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=) | `70.29% <0.00%> (-0.24%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `92.76% <0.00%> (+0.09%)` | :arrow_up: | | [src/adaptors/http1/http1\_codec.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX2NvZGVjLmM=) | `85.28% <0.00%> (+0.12%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `89.53% <0.00%> (+0.29%)` | :arrow_up: | | [src/router\_core/delivery.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2RlbGl2ZXJ5LmM=) | `93.33% <0.00%> (+0.37%)` | :arrow_up: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `87.39% <0.00%> (+1.13%)` | :arrow_up: | | [src/router\_core/agent\_address.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1146/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2FkZHJlc3MuYw==) | `89.76% <0.00%> (+1.57%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1146?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334876#comment-17334876
]
ASF GitHub Bot commented on DISPATCH-2088:
--
ChugR commented on pull request #1172:
URL: https://github.com/apache/qpid-dispatch/pull/1172#issuecomment-828628426
This patch is misguided. The router callbacks were initiated on a raw
connection wake callback and had the proper thread already.
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334877#comment-17334877
]
ASF GitHub Bot commented on DISPATCH-2088:
--
ChugR closed pull request #1172:
URL: https://github.com/apache/qpid-dispatch/pull/1172
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR closed pull request #1172: DISPATCH-2088: Reschedule router event I/O on thread that owns raw connection
ChugR closed pull request #1172: URL: https://github.com/apache/qpid-dispatch/pull/1172 -- 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. 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-dispatch] ChugR commented on pull request #1172: DISPATCH-2088: Reschedule router event I/O on thread that owns raw connection
ChugR commented on pull request #1172: URL: https://github.com/apache/qpid-dispatch/pull/1172#issuecomment-828628426 This patch is misguided. The router callbacks were initiated on a raw connection wake callback and had the proper thread already. -- 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. 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-2088) SEGV in qd_buffer_dec_fanout
[ https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334872#comment-17334872 ] ASF GitHub Bot commented on DISPATCH-2088: -- mgoulish commented on pull request #1172: URL: https://github.com/apache/qpid-dispatch/pull/1172#issuecomment-828614025 With this patch I have a failure at the end of iteration 5 . Here's the backtrace: (gdb) thread apply all bt Thread 33 (Thread 0x7fb055ffb640 (LWP 57065)): #0 0x7fb0bd83450c in send () from /lib64/libpthread.so.0 #1 0x7fb0bd86f718 in snd (s=512, b=, fd=21) at /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:333 #2 pni_raw_write (send=, set_error=, sock=, conn=) at /home/mick/latest/qpid-proton/c/src/proactor/raw_connection.c:566 #3 pni_raw_write (send=, set_error=, sock=21, conn=0x7fb078079830) at /home/mick/latest/qpid-proton/c/src/proactor/raw_connection.c:554 #4 pni_raw_connection_process (sched_ready=, t=0x7fb078079770) at /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:388 #5 process (tsk=0x7fb078079770) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2230 #6 next_event_batch (p=, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2419 #7 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #8 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #9 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x7fb0a5ffb640 (LWP 57045)): --Type for more, q to quit, c to continue without paging-- #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb084000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x7fb07effd640 (LWP 57056)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb04b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 --Type for more, q to quit, c to continue without paging-- Thread 30 (Thread 0x7fb054ff9640 (LWP 57067)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb01c000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x7fb07d7fa640 (LWP 57059)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb064000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 --Type for more, q to quit, c to continue without paging-- Thread 28 (Thread 0x7fb07e7fc640 (LWP 57057)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb06c000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 27
[GitHub] [qpid-dispatch] mgoulish commented on pull request #1172: DISPATCH-2088: Reschedule router event I/O on thread that owns raw connection
mgoulish commented on pull request #1172: URL: https://github.com/apache/qpid-dispatch/pull/1172#issuecomment-828614025 With this patch I have a failure at the end of iteration 5 . Here's the backtrace: (gdb) thread apply all bt Thread 33 (Thread 0x7fb055ffb640 (LWP 57065)): #0 0x7fb0bd83450c in send () from /lib64/libpthread.so.0 #1 0x7fb0bd86f718 in snd (s=512, b=, fd=21) at /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:333 #2 pni_raw_write (send=, set_error=, sock=, conn=) at /home/mick/latest/qpid-proton/c/src/proactor/raw_connection.c:566 #3 pni_raw_write (send=, set_error=, sock=21, conn=0x7fb078079830) at /home/mick/latest/qpid-proton/c/src/proactor/raw_connection.c:554 #4 pni_raw_connection_process (sched_ready=, t=0x7fb078079770) at /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:388 #5 process (tsk=0x7fb078079770) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2230 #6 next_event_batch (p=, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2419 #7 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #8 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #9 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x7fb0a5ffb640 (LWP 57045)): --Type for more, q to quit, c to continue without paging-- #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb084000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x7fb07effd640 (LWP 57056)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb04b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 --Type for more, q to quit, c to continue without paging-- Thread 30 (Thread 0x7fb054ff9640 (LWP 57067)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb01c000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x7fb07d7fa640 (LWP 57059)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb064000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 --Type for more, q to quit, c to continue without paging-- Thread 28 (Thread 0x7fb07e7fc640 (LWP 57057)): #0 0x7fb0bd8306c2 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fb0bd86ecbb in suspend (ts=0x7fb06c000b60, p=0x2485d30) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393 #2 next_event_batch (p=0x2485d30, can_block=true) at /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455 #3 0x7fb0bd94df5f in thread_run (arg=0x2291c00) at /home/mick/latest/qpid-dispatch/src/server.c:1105 #4 0x7fb0bd82a3f9 in start_thread () from /lib64/libpthread.so.0 #5 0x7fb0bd4a9b53 in clone () from /lib64/libc.so.6 Thread 27 (Thread 0x7fb0567fc640 (LWP 57064)): #0 0x7fb0bd83450c in send () from /lib64/libpthread.so.0 #1 0x7fb0bd86f718 in snd (s=512, b=, fd=27) at /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:333 #2 pni_raw_write
[jira] [Assigned] (DISPATCH-2055) AddressSanitizer: heap-use-after-free in write_log during system_tests_qdmanage
[
https://issues.apache.org/jira/browse/DISPATCH-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-2055:
---
Assignee: Ganesh Murthy
> AddressSanitizer: heap-use-after-free in write_log during
> system_tests_qdmanage
> ---
>
> Key: DISPATCH-2055
> URL: https://issues.apache.org/jira/browse/DISPATCH-2055
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.17.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/498853046#L5728
> {noformat}
> 29: Process 13857 error: exit code 1, expected -1
> 29: qdrouterd -c test_router_1.conf -I
> /home/travis/build/apache/qpid-dispatch/python
> 29:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_qdmanage/QdmanageTest/setUpClass/test_router_1-2.cmd
> 29:
> 29: =
> 29: ==13857==ERROR: AddressSanitizer: heap-use-after-free on address
> 0xaca04ba8 at pc 0xb1f23f34 bp 0xa5cf2770 sp 0xa5cf2768
> 29: READ of size 8 at 0xaca04ba8 thread T2
> 29: #0 0xb1f23f30 in write_log
> /home/travis/build/apache/qpid-dispatch/src/log.c:343:22
> 29: #1 0xb1f23f30 in qd_vlog_impl
> /home/travis/build/apache/qpid-dispatch/src/log.c:437:5
> 29: #2 0xb1f24d44 in qd_log_impl
> /home/travis/build/apache/qpid-dispatch/src/log.c:456:3
> 29: #3 0xb1b482c8 in pni_tracer_to_log_sink
> /home/travis/build/apache/qpid-dispatch/qpid-proton/c/src/core/transport.c:2874:3
> 29:
> 29: 0xaca04ba8 is located 24 bytes inside of 48-byte region
> [0xaca04b90,0xaca04bc0)
> 29: freed by thread T3 here:
> 29: #0 0x48f30c in free
> (/home/travis/build/apache/qpid-dispatch/build/router/qdrouterd+0x48f30c)
> 29: #1 0xb1f27c64 in qd_log_entity
> /home/travis/build/apache/qpid-dispatch/src/log.c:555:17
> 29: #2 0xacf09ff4 (/lib/aarch64-linux-gnu/libffi.so.7+0x5ff4)
> 29: #3 0xacf097c8 (/lib/aarch64-linux-gnu/libffi.so.7+0x57c8)
> 29: #4 0xacddfd20 in _ctypes_callproc
> (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-aarch64-linux-gnu.so+0xfd20)
> 29: #5 0xacde0334
> (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-aarch64-linux-gnu.so+0x10334)
> 29: #6 0xb17dc604 in _PyObject_MakeTpCall
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x299604)
> 29: #7 0xb15b6698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73698)
> 29: #8 0xb15bd888 in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7a888)
> 29: #9 0xb15c1698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7e698)
> 29: #10 0xb17dc8a0
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x2998a0)
> 29: #11 0xb15b6624
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73624)
> 29: #12 0xb15bd888 in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7a888)
> 29: #13 0xb15c1698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7e698)
> 29: #14 0xb17dc8a0
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x2998a0)
> 29: #15 0xb15b6624
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73624)
> 29: #16 0xb15bb3bc in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x783bc)
> 29: #17 0xb15c1698
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x7e698)
> 29: #18 0xb15b6624
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x73624)
> 29: #19 0xb15b75a0 in _PyEval_EvalFrameDefault
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x745a0)
> 29: #20 0xb1702958 in _PyEval_EvalCodeWithName
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x1bf958)
> 29: #21 0xb17dbbbc in _PyFunction_Vectorcall
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x298bbc)
> 29: #22 0xb17dc808
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x299808)
> 29: #23 0xb17dcf34
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x299f34)
> 29: #24 0xb17dd8c0 in PyObject_CallFunction
> (/lib/aarch64-linux-gnu/libpython3.8.so.1.0+0x29a8c0)
> 29: #25 0xb1f7e4d0 in qd_io_rx_handler
> /home/travis/build/apache/qpid-dispatch/src/python_embedded.c:662:23
> 29: #26 0xb200eb54 in qdr_forward_on_message
> /home/travis/build/apache/qpid-dispatch/src/router_core/forwarder.c:341:28
> 29: #27 0xb2031bb4 in qdr_general_handler
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:903:9
> 29: #28 0xb20ee754 in qd_timer_visit
> /home/travis/build/apache/qpid-dispatch/src/timer.c:205:9
> 29: #29 0xb20e1754 in handle
>
[GitHub] [qpid-dispatch] jiridanek opened a new pull request #1173: NO-JIRA Update clang to 12 in Travis CI
jiridanek opened a new pull request #1173: URL: https://github.com/apache/qpid-dispatch/pull/1173 -- 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. 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-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334801#comment-17334801
]
ASF GitHub Bot commented on DISPATCH-2088:
--
grs commented on pull request #1172:
URL: https://github.com/apache/qpid-dispatch/pull/1172#issuecomment-828544677
Isn't this what already happens though? I.e. core calls activate, adaptor
calls wake and the pn_connection_process on the io thread in response to WAKE,
and that is when the callbacks into the adaptor are made. I.e. I don't believe
this is necessary or a fix for DISPATCH-2088.
As mentioned on the JIRA I think the fix is to move the flush_outgoing_buffs
call from free_qdr_tcp_connection to handle disconnected.
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] grs commented on pull request #1172: DISPATCH-2088: Reschedule router event I/O on thread that owns raw connection
grs commented on pull request #1172: URL: https://github.com/apache/qpid-dispatch/pull/1172#issuecomment-828544677 Isn't this what already happens though? I.e. core calls activate, adaptor calls wake and the pn_connection_process on the io thread in response to WAKE, and that is when the callbacks into the adaptor are made. I.e. I don't believe this is necessary or a fix for DISPATCH-2088. As mentioned on the JIRA I think the fix is to move the flush_outgoing_buffs call from free_qdr_tcp_connection to handle disconnected. -- 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. 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-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334794#comment-17334794
]
ASF GitHub Bot commented on DISPATCH-2088:
--
ChugR opened a new pull request #1172:
URL: https://github.com/apache/qpid-dispatch/pull/1172
Handlers for router events do not directly call handle_incoming and
handle_outgoing. Instead they schedule wake and let proton provide a safe
thread in the wake callback for those calls to incoming and outgoing.
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR opened a new pull request #1172: DISPATCH-2088: Reschedule router event I/O on thread that owns raw connection
ChugR opened a new pull request #1172: URL: https://github.com/apache/qpid-dispatch/pull/1172 Handlers for router events do not directly call handle_incoming and handle_outgoing. Instead they schedule wake and let proton provide a safe thread in the wake callback for those calls to incoming and outgoing. -- 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. 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-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334779#comment-17334779
]
Gordon Sim commented on DISPATCH-2088:
--
{quote}There are at several cases where router calls into TCP adaptor code lead
to calling handle_incoming on a thread that does not own the underlying TCP
connection.
* qdr_tcp_second_attach
* qdr_tcp_flow
* qdr_tcp_deliver
* qdr_tcp_delivery_update
The fix is for these handlers is to call thread-safe connection_wake and then
call handle_incoming during the CONNECTION_WAKE event when the thread owns the
raw connection.
{quote}
Is it not the case that those callbacks occur when calling
qdr_connection_process() which is done on the io thread?
I think flush_outgoing_buffs() should be called in handle_disconnected, which
always happens on the IO thread, and not in free_qdr_tcp_connection, which
actually happens on the core.
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] codecov-commenter commented on pull request #1171: NO-JIRA: extend test timeout for s390x platform
codecov-commenter commented on pull request #1171: URL: https://github.com/apache/qpid-dispatch/pull/1171#issuecomment-828507871 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1171](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (9be1478) into [main](https://codecov.io/gh/apache/qpid-dispatch/commit/d2f47a19077e604bce22513955dc9466192ca4ca?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (d2f47a1) will **decrease** coverage by `0.00%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) ```diff @@Coverage Diff @@ ## main#1171 +/- ## == - Coverage 84.23% 84.22% -0.01% == Files 112 112 Lines 2766727667 == - Hits2330423302 -2 - Misses 4363 4365 +2 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...c/router\_core/modules/test\_hooks/core\_test\_hooks.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvdGVzdF9ob29rcy9jb3JlX3Rlc3RfaG9va3MuYw==) | `92.03% <0.00%> (-1.28%)` | :arrow_down: | | [src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=) | `70.29% <0.00%> (-0.24%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `89.14% <0.00%> (-0.10%)` | :arrow_down: | | [src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3NlcnZlci5j) | `86.79% <0.00%> (+0.10%)` | :arrow_up: | | [src/router\_core/delivery.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2RlbGl2ZXJ5LmM=) | `93.14% <0.00%> (+0.18%)` | :arrow_up: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3BhcnNlLmM=) | `87.08% <0.00%> (+0.21%)` | :arrow_up: | | [src/adaptors/http1/http1\_server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1171/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX3NlcnZlci5j) | `84.88% <0.00%> (+0.29%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=footer_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Last update [d2f47a1...9be1478](https://codecov.io/gh/apache/qpid-dispatch/pull/1171?src=pr=lastupdated_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Read the [comment
[jira] [Resolved] (DISPATCH-2090) [tools] Scraper mishandling non-terminal dispositions
[ https://issues.apache.org/jira/browse/DISPATCH-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke resolved DISPATCH-2090. Resolution: Fixed Fixed at commit 04c10019 > [tools] Scraper mishandling non-terminal dispositions > - > > Key: DISPATCH-2090 > URL: https://issues.apache.org/jira/browse/DISPATCH-2090 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.15.0 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > Fix For: 1.16.0 > > > * last disposition may arrive before transfers yielding a negative > disposition delta time > * the tool should not complain when non-terminal dispositions are overwritten -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2090) [tools] Scraper mishandling non-terminal dispositions
[ https://issues.apache.org/jira/browse/DISPATCH-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334759#comment-17334759 ] ASF subversion and git services commented on DISPATCH-2090: --- Commit 04c10019bd69427ef70566087ec2f1bb945ffc86 in qpid-dispatch's branch refs/heads/main from Charles E. Rolke [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=04c1001 ] DISPATCH-2090: [tools] Scraper handles non-terminal dispositions Non-terminal dispositions were added to effect TCP adaptor flow control in the 1.16 release. Scraper needs adjustments to handle them. * Report negative disposition delta times as 0 seconds * Allow non-terminal dispositions to be overwritten without logging an error > [tools] Scraper mishandling non-terminal dispositions > - > > Key: DISPATCH-2090 > URL: https://issues.apache.org/jira/browse/DISPATCH-2090 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.15.0 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > Fix For: 1.16.0 > > > * last disposition may arrive before transfers yielding a negative > disposition delta time > * the tool should not complain when non-terminal dispositions are overwritten -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2090) [tools] Scraper mishandling non-terminal dispositions
[ https://issues.apache.org/jira/browse/DISPATCH-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke updated DISPATCH-2090: --- Priority: Blocker (was: Major) > [tools] Scraper mishandling non-terminal dispositions > - > > Key: DISPATCH-2090 > URL: https://issues.apache.org/jira/browse/DISPATCH-2090 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.15.0 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > > * last disposition may arrive before transfers yielding a negative > disposition delta time > * the tool should not complain when non-terminal dispositions are overwritten -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2090) [tools] Scraper mishandling non-terminal dispositions
[ https://issues.apache.org/jira/browse/DISPATCH-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke updated DISPATCH-2090: --- Fix Version/s: 1.16.0 > [tools] Scraper mishandling non-terminal dispositions > - > > Key: DISPATCH-2090 > URL: https://issues.apache.org/jira/browse/DISPATCH-2090 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.15.0 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > Fix For: 1.16.0 > > > * last disposition may arrive before transfers yielding a negative > disposition delta time > * the tool should not complain when non-terminal dispositions are overwritten -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] kgiusti opened a new pull request #1171: NO-JIRA: extend test timeout for s390x platform
kgiusti opened a new pull request #1171: URL: https://github.com/apache/qpid-dispatch/pull/1171 -- 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. 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] [Resolved] (DISPATCH-2089) [tools] Scraper not html-escaping user transfer data properly
[ https://issues.apache.org/jira/browse/DISPATCH-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke resolved DISPATCH-2089. Resolution: Fixed Fixed at commit 4da6849 > [tools] Scraper not html-escaping user transfer data properly > - > > Key: DISPATCH-2089 > URL: https://issues.apache.org/jira/browse/DISPATCH-2089 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > Fix For: 1.16.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2089) [tools] Scraper not html-escaping user transfer data properly
[ https://issues.apache.org/jira/browse/DISPATCH-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke updated DISPATCH-2089: --- Fix Version/s: 1.16.0 > [tools] Scraper not html-escaping user transfer data properly > - > > Key: DISPATCH-2089 > URL: https://issues.apache.org/jira/browse/DISPATCH-2089 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > Fix For: 1.16.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2089) [tools] Scraper not html-escaping user transfer data properly
[ https://issues.apache.org/jira/browse/DISPATCH-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke updated DISPATCH-2089: --- Priority: Blocker (was: Major) > [tools] Scraper not html-escaping user transfer data properly > - > > Key: DISPATCH-2089 > URL: https://issues.apache.org/jira/browse/DISPATCH-2089 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334745#comment-17334745
]
Fernando Giorgetti commented on DISPATCH-2088:
--
I have just reproduced it and found a similar bt:
{noformat}
qdrouterd: /build/qpid-dispatch-src/src/posix/threading.c:58: sys_mutex_lock:
Assertion `result == 0' failed.
#4 0x77f4f831 in sys_mutex_lock (mutex=) at
/build/qpid-dispatch-src/src/posix/threading.c:58
#5 0x77f46d2a in qd_message_stream_data_release
(stream_data=0x7fffdc0a2e48) at /build/qpid-dispatch-src/src/message.c:2619
#6 0x77f2e135 in flush_outgoing_buffs (conn=conn@entry=0x6c3c08) at
/build/qpid-dispatch-src/src/adaptors/tcp_adaptor.c:431
#7 0x77f3191e in free_qdr_tcp_connection (tc=0x6c3c08) at
/build/qpid-dispatch-src/src/adaptors/tcp_adaptor.c:455
#8 0x77f6c635 in router_core_thread (arg=0x603320) at
/build/qpid-dispatch-src/src/router_core/router_core_thread.c:239
#9 0x77e7b4c0 in start_thread () from /lib64/libpthread.so.0
#10 0x779b1133 in clone () from /lib64/libc.so.6{noformat}
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334743#comment-17334743
]
michael goulish commented on DISPATCH-2088:
---
Here you go!
(gdb) thread apply all bt
{color:#172b4d}Thread 33{color} (Thread 0x7fa320ff9640 (LWP 53393)):
#0 0x7fa343d7f6c2 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x7fa343dbdcbb in suspend (ts=0x7fa2fb60, p=0xd46d30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393
#2 next_event_batch (p=0xd46d30, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455
#3 0x7fa343e9cf9f in thread_run (arg=0xb52c00) at
/home/mick/latest/qpid-dispatch/src/server.c:1105
#4 0x7fa343d793f9 in start_thread () from /lib64/libpthread.so.0
#5 0x7fa3439f8b53 in clone () from /lib64/libc.so.6
{color:#172b4d}Thread 32{color} (Thread 0x7fa2e8ff9640 (LWP 53408)):
#0 0x7fa343d7f6c2 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x7fa343dbdcbb in suspend (ts=0x7fa2a8000b60, p=0xd46d30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393
#2 next_event_batch (p=0xd46d30, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455
#3 0x7fa343e9cf9f in thread_run (arg=0xb52c00) at
/home/mick/latest/qpid-dispatch/src/server.c:1105
#4 0x7fa343d793f9 in start_thread () from /lib64/libpthread.so.0
--Type for more, q to quit, c to continue without paging--
#5 0x7fa3439f8b53 in clone () from /lib64/libc.so.6
{color:#172b4d}Thread 31{color} (Thread 0x7fa2e37fe640 (LWP 53409)):
#0 0x7fa343d7f6c2 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x7fa343dbdcbb in suspend (ts=0x7fa2bc000b60, p=0xd46d30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393
#2 next_event_batch (p=0xd46d30, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455
#3 0x7fa343e9cf9f in thread_run (arg=0xb52c00) at
/home/mick/latest/qpid-dispatch/src/server.c:1105
#4 0x7fa343d793f9 in start_thread () from /lib64/libpthread.so.0
#5 0x7fa3439f8b53 in clone () from /lib64/libc.so.6
Thread 30 (Thread 0x7fa30effd640 (LWP 53396)):
#0 0x7fa343d7f6c2 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x7fa343dbdcbb in suspend (ts=0x7fa30b60, p=0xd46d30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393
#2 next_event_batch (p=0xd46d30, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455
#3 0x7fa343e9cf9f in thread_run (arg=0xb52c00) at
/home/mick/latest/qpid-dispatch/src/server.c:1105
--Type for more, q to quit, c to continue without paging--
#4 0x7fa343d793f9 in start_thread () from /lib64/libpthread.so.0
#5 0x7fa3439f8b53 in clone () from /lib64/libc.so.6
Thread 29 (Thread 0x7fa30f7fe640 (LWP 53395)):
#0 0x7fa343d7f6c2 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x7fa343dbdcbb in suspend (ts=0x7fa2fc000b60, p=0xd46d30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393
#2 next_event_batch (p=0xd46d30, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455
#3 0x7fa343e9cf9f in thread_run (arg=0xb52c00) at
/home/mick/latest/qpid-dispatch/src/server.c:1105
#4 0x7fa343d793f9 in start_thread () from /lib64/libpthread.so.0
#5 0x7fa3439f8b53 in clone () from /lib64/libc.so.6
Thread 28 (Thread 0x7fa30cff9640 (LWP 53400)):
#0 0x7fa343d7f6c2 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x7fa343dbdcbb in suspend (ts=0x7fa2e4000b60, p=0xd46d30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:393
#2 next_event_batch (p=0xd46d30, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2455
#3 0x7fa343e9cf9f in thread_run (arg=0xb52c00) at
/home/mick/latest/qpid-di--Type for more, q to quit, c to continue
without paging--c
spatch/src/server.c:1105
#4 0x7fa343d793f9 in start_thread () from /lib64/libpthread.so.0
#5 0x7fa3439f8b53 in clone () from /lib64/libc.so.6
*{color:#de350b}Thread 27{color}* (Thread 0x7fa2eb7fe640 (LWP 53403)):
#0 0x7fa343d8350c in send () from /lib64/libpthread.so.0
#1 0x7fa343dbe718 in snd (s=512, b=, fd=25) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:333
#2 pni_raw_write (send=, set_error=,
sock=, conn=) at
/home/mick/latest/qpid-proton/c/src/proactor/raw_connection.c:566
#3 pni_raw_write (send=, set_error=, sock=25,
conn=0x7fa2dc129cf0) at
/home/mick/latest/qpid-proton/c/src/proactor/raw_connection.c:554
#4 pni_raw_connection_process (sched_ready=, t=0x7fa2dc129c30)
at /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:388
#5 process (tsk=0x7fa2dc129c30) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2230
#6 next_event_batch (p=, can_block=true) at
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334741#comment-17334741
]
Charles E. Rolke commented on DISPATCH-2088:
I'm suspecting that there is a threading violation with proton and ownership of
a raw connection.
There are at several cases where router calls into TCP adaptor code lead to
calling handle_incoming on a thread that does not own the underlying TCP
connection.
* qdr_tcp_second_attach
* qdr_tcp_flow
* qdr_tcp_deliver
* qdr_tcp_delivery_update
The fix is for these handlers is to call thread-safe connection_wake and then
call handle_incoming during the CONNECTION_WAKE event when the thread owns the
raw connection.
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles E. Rolke updated DISPATCH-2088:
---
Fix Version/s: 1.16.0
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
> Fix For: 1.16.0
>
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles E. Rolke updated DISPATCH-2088:
---
Priority: Blocker (was: Major)
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Blocker
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles E. Rolke reassigned DISPATCH-2088:
--
Assignee: Charles E. Rolke
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Charles E. Rolke
>Priority: Major
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334720#comment-17334720
]
Ken Giusti commented on DISPATCH-2088:
--
Thanks for the log file. We've hit a crash in CI (no core unfortunately), but
the log file in that crash is similar (seg fault immediately after
PN_RAW_CONNECTION_DISCONNECTED)
Since Debug is masking the problem it's _probably_ timing related.
Are you able to generate a core file (RelWithDebInfo build of course)? If so
it would be useful to get backtraces of all threads at the moment of the crash
(in gdb that would be "thread apply all bt" command).
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Priority: Major
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2088) SEGV in qd_buffer_dec_fanout
[
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334707#comment-17334707
]
michael goulish commented on DISPATCH-2088:
---
I cannot repro with Debug build.
400 iterations with no failure.
> SEGV in qd_buffer_dec_fanout
>
>
> Key: DISPATCH-2088
> URL: https://issues.apache.org/jira/browse/DISPATCH-2088
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Priority: Major
>
> *code from 2021-04-26-afternoon*
> {
> dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04
> proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936
> }
>
> *Test*
> * Doing 1-router TCP throughput testing across high-bandwidth link.
> * Router has 32 worker threads.
> * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams.
> * Router is sustaining 10+ Gbit/sec during test.
> * SEGV happens at end of test.
>
> Here's the backtrace:
>
> {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color}
> {color:#de350b}#1 sys_atomic_dec (ref=0x14){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color}
> {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color}
> {color:#de350b}#3 qd_message_stream_data_release
> (stream_data=0x7f01b80038c8){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color}
> {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs
> (conn=conn@entry=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color}
> {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection
> (tc=0x7f0218012a88){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color}
> {color:#de350b}#6 0x7f023707491d in router_core_thread
> (arg=0x1e6ccb0){color}
> {color:#de350b} at
> /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color}
> {color:#de350b}#7 0x7f0236f663f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8520) ReadPendingException thrown by Broker-J intermittently
[
https://issues.apache.org/jira/browse/QPID-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyrre updated QPID-8520:
Description:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly after these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null prevented
AC.ReadCB@108ec429{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
Exception while notifying connection
PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
{quote}
>From the client side log:
{quote}org.springframework.web.client.ResourceAccessException: I/O error on
POST request for "https://localhost:49201/api/latest/queue/default/localhost/":
Remote host terminated the handshake; nested exception is
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
{quote}
I am fully aware that this might be a bit too little to go by, but I have tried
in to create a reproducible code snippet, but cannot find a way to make the
error occur in a stable and reproducible way. I am also aware that this might
be caused by a number of other things, but figured thia would be a good start
to try to find out what to do about it.
was:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly aft these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null
[jira] [Updated] (QPID-8520) ReadPendingException thrown by Broker-J intermittently
[
https://issues.apache.org/jira/browse/QPID-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyrre updated QPID-8520:
Description:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly aft these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null prevented
AC.ReadCB@108ec429{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
Exception while notifying connection
PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
{quote}
>From the client side log:
{quote}org.springframework.web.client.ResourceAccessException: I/O error on
POST request for "https://localhost:49201/api/latest/queue/default/localhost/":
Remote host terminated the handshake; nested exception is
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
{quote}
I am fully aware that this might be a bit too little to go by, but I have tried
in to create a reproducible code snippet, but cannot find a way to make the
error occur in a stable and reproducible way. I am also aware that this might
be caused by a number of other things, but figured thia would be a good start
to try to find out what to do about it.
was:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly after these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null
[GitHub] [qpid-dispatch] jiridanek commented on pull request #1169: NO-JIRA: Skip the GHA Docs job until Proton 0.34.0 Ubuntu package is published
jiridanek commented on pull request #1169: URL: https://github.com/apache/qpid-dispatch/pull/1169#issuecomment-828379496 I came to this _wanting_ to use the Ubuntu deb package. It avoids dependency between the jobs, they can run concurrently. And I got discouraged from pursuing a different way of doing things (I am no longer sure what exactly it was) after hitting https://issues.apache.org/jira/browse/DISPATCH-1995. -- 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. 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-dispatch] gemmellr commented on pull request #1169: NO-JIRA: Skip the GHA Docs job until Proton 0.34.0 Ubuntu package is published
gemmellr commented on pull request #1169: URL: https://github.com/apache/qpid-dispatch/pull/1169#issuecomment-828362141 Why does this bit need to use a package when the test etc bits have already built proton? -- 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. 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] [Comment Edited] (PROTON-2095) Move away from SWIG to CFFI
[
https://issues.apache.org/jira/browse/PROTON-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325666#comment-17325666
]
Jiri Daněk edited comment on PROTON-2095 at 4/28/21, 10:17 AM:
---
h3. My CFFI references
[https://medium.com/paypal-tech/python-by-the-c-side-1f82fc94c4ad]
Some hints about Setuptools,
[https://carsonip.me/posts/writing-a-python-wrapper-for-html2text-using-cffi/]
We want to use “out-of-line” + “API mode” CFFI with setuptools,
[https://cffi.readthedocs.io/en/release-1.9/cdef.html]
Worked example for a relatively small C API
[https://aldnav.com/blog/writing-a-geohash-wrapper-using-cffi/]
Python 3 strings
[https://cffi.readthedocs.io/en/release-1.9/using.html?highlight=re#python-3-support]
Automatic generation of .pyi typing stub files
[https://groups.google.com/g/python-cffi/c/6V8PBjA6ZJ4]
Slowest part of cffi seems to be processing the data in interpreted code, in
and out (will be better in PyPy?)
[https://blog.ian.stapletoncordas.co/2018/01/making-python-faster-with-rust-and-cffi-or-not.html]
More perf, Cython vs cffi
[https://zpz.github.io/blog/speeding-up-python-with-c-and-cffi/]
h4. Build
Proton now has two modes. First, swig generates c code, then the cmake swig
module compiles that; used in sysinstall binding and in running tests. Second,
setuptools either locates installed Proton in the system or builds it from
sources and creates a wheel.
I dislike the mode of working of pip install picking up systemwide library and
building the binding for it. But cffi seems to be fine with it, it even has
pkgconfig integration on Linux. I'd prefer using CMake even in building the
wheel, but I am not sure how practical that would be.
Python has multiple toolsets to build packages: distutils (1st party),
setuptools (2nd party, sort of) (https://setuptools.readthedocs.io/en/stable),
and 3rd party scikit-build (https://scikit-build.readthedocs.io/en/latest),
flit, hatch, poetry, and other
(https://packaging.python.org/key_projects/#non-pypa-projects)
Building a minimal custom tooling is possible too, e.g. like the PyZMQ code
currently used in Proton.
https://martinopilia.com/posts/2018/09/15/building-python-extension.html
https://gist.github.com/hovren/5b62175731433c741d07ee6f482e2936
https://stackoverflow.com/questions/42585210/extending-setuptools-extension-to-use-cmake-in-setup-py
https://pypi.org/project/cmaketools/
Packaging tutorials: https://packaging.python.org/tutorials/packaging-projects/
https://packaging.python.org/guides/distributing-packages-using-setuptools/
https://cffi.readthedocs.io/en/latest/cdef.html#preparing-and-distributing-modules
https://www.benjack.io/2018/02/02/python-cpp-revisited.html
[~astitcher] btw,
https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
;P
keep using tox to run python tests
setup.py can take arguments? from
https://stackoverflow.com/questions/16787649/how-to-configure-python-cffi-library-to-use-mingw
{code}
cd cffi-src-dir
python setup.py config --compiler=mingw32 build --compiler=mingw32 install
cd ..
{code}
was (Author: jdanek):
h3. My CFFI references
[https://medium.com/paypal-tech/python-by-the-c-side-1f82fc94c4ad]
Some hints about Setuptools,
[https://carsonip.me/posts/writing-a-python-wrapper-for-html2text-using-cffi/]
We want to use “out-of-line” + “API mode” CFFI with setuptools,
[https://cffi.readthedocs.io/en/release-1.9/cdef.html]
Worked example for a relatively small C API
[https://aldnav.com/blog/writing-a-geohash-wrapper-using-cffi/]
Python 3 strings
[https://cffi.readthedocs.io/en/release-1.9/using.html?highlight=re#python-3-support]
Automatic generation of .pyi typing stub files
[https://groups.google.com/g/python-cffi/c/6V8PBjA6ZJ4]
Slowest part of cffi seems to be processing the data in interpreted code, in
and out (will be better in PyPy?)
[https://blog.ian.stapletoncordas.co/2018/01/making-python-faster-with-rust-and-cffi-or-not.html]
More perf, Cython vs cffi
[https://zpz.github.io/blog/speeding-up-python-with-c-and-cffi/]
h4. Build
Proton now has two modes. First, swig generates c code, then the cmake swig
module compiles that; used in sysinstall binding and in running tests. Second,
setuptools either locates installed Proton in the system or builds it from
sources and creates a wheel.
I dislike the mode of working of pip install picking up systemwide library and
building the binding for it. But cffi seems to be fine with it, it even has
pkgconfig integration on Linux. I'd prefer using CMake even in building the
wheel, but I am not sure how practical that would be.
Python has multiple toolsets to build packages: distutils (1st party),
setuptools (2nd party, sort of) (https://setuptools.readthedocs.io/en/stable),
and 3rd party scikit-build (https://scikit-build.readthedocs.io/en/latest),
flit,
[jira] [Comment Edited] (PROTON-2095) Move away from SWIG to CFFI
[
https://issues.apache.org/jira/browse/PROTON-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325666#comment-17325666
]
Jiri Daněk edited comment on PROTON-2095 at 4/28/21, 10:16 AM:
---
h3. My CFFI references
[https://medium.com/paypal-tech/python-by-the-c-side-1f82fc94c4ad]
Some hints about Setuptools,
[https://carsonip.me/posts/writing-a-python-wrapper-for-html2text-using-cffi/]
We want to use “out-of-line” + “API mode” CFFI with setuptools,
[https://cffi.readthedocs.io/en/release-1.9/cdef.html]
Worked example for a relatively small C API
[https://aldnav.com/blog/writing-a-geohash-wrapper-using-cffi/]
Python 3 strings
[https://cffi.readthedocs.io/en/release-1.9/using.html?highlight=re#python-3-support]
Automatic generation of .pyi typing stub files
[https://groups.google.com/g/python-cffi/c/6V8PBjA6ZJ4]
Slowest part of cffi seems to be processing the data in interpreted code, in
and out (will be better in PyPy?)
[https://blog.ian.stapletoncordas.co/2018/01/making-python-faster-with-rust-and-cffi-or-not.html]
More perf, Cython vs cffi
[https://zpz.github.io/blog/speeding-up-python-with-c-and-cffi/]
h4. Build
Proton now has two modes. First, swig generates c code, then the cmake swig
module compiles that; used in sysinstall binding and in running tests. Second,
setuptools either locates installed Proton in the system or builds it from
sources and creates a wheel.
I dislike the mode of working of pip install picking up systemwide library and
building the binding for it. But cffi seems to be fine with it, it even has
pkgconfig integration on Linux. I'd prefer using CMake even in building the
wheel, but I am not sure how practical that would be.
Python has multiple toolsets to build packages: distutils (1st party),
setuptools (2nd party, sort of) (https://setuptools.readthedocs.io/en/stable),
and 3rd party scikit-build (https://scikit-build.readthedocs.io/en/latest),
flit, hatch, poetry, and other
Building a minimal custom tooling is possible too, e.g. like the PyZMQ code
currently used in Proton.
https://martinopilia.com/posts/2018/09/15/building-python-extension.html
https://gist.github.com/hovren/5b62175731433c741d07ee6f482e2936
https://stackoverflow.com/questions/42585210/extending-setuptools-extension-to-use-cmake-in-setup-py
https://pypi.org/project/cmaketools/
Packaging tutorials: https://packaging.python.org/tutorials/packaging-projects/
https://packaging.python.org/guides/distributing-packages-using-setuptools/
https://cffi.readthedocs.io/en/latest/cdef.html#preparing-and-distributing-modules
https://www.benjack.io/2018/02/02/python-cpp-revisited.html
[~astitcher] btw,
https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
;P
keep using tox to run python tests
setup.py can take arguments? from
https://stackoverflow.com/questions/16787649/how-to-configure-python-cffi-library-to-use-mingw
{code}
cd cffi-src-dir
python setup.py config --compiler=mingw32 build --compiler=mingw32 install
cd ..
{code}
was (Author: jdanek):
h3. My CFFI references
[https://medium.com/paypal-tech/python-by-the-c-side-1f82fc94c4ad]
Some hints about Setuptools,
[https://carsonip.me/posts/writing-a-python-wrapper-for-html2text-using-cffi/]
We want to use “out-of-line” + “API mode” CFFI with setuptools,
[https://cffi.readthedocs.io/en/release-1.9/cdef.html]
Worked example for a relatively small C API
[https://aldnav.com/blog/writing-a-geohash-wrapper-using-cffi/]
Python 3 strings
[https://cffi.readthedocs.io/en/release-1.9/using.html?highlight=re#python-3-support]
Automatic generation of .pyi typing stub files
[https://groups.google.com/g/python-cffi/c/6V8PBjA6ZJ4]
Slowest part of cffi seems to be processing the data in interpreted code, in
and out (will be better in PyPy?)
[https://blog.ian.stapletoncordas.co/2018/01/making-python-faster-with-rust-and-cffi-or-not.html]
More perf, Cython vs cffi
[https://zpz.github.io/blog/speeding-up-python-with-c-and-cffi/]
> Move away from SWIG to CFFI
> ---
>
> Key: PROTON-2095
> URL: https://issues.apache.org/jira/browse/PROTON-2095
> Project: Qpid Proton
> Issue Type: Wish
> Components: python-binding
>Affects Versions: proton-c-future, proton-c-0.29.0
>Reporter: Omer Katz
>Priority: Major
> Fix For: proton-c-future
>
>
> SWIG is fine but we're not using it for anything other than exporting all of
> proton-c's API as is.
> Unfortunately SWIG only generates CPython extension bindings. This may be a
> problem on PyPy where CPython extensions are either slow or simply won't
> compile.
> Unlike SWIG, CFFI is portable both on CPython and PyPy.
> It also satisfies the same requirements as SWIG currently does.
> In addition, calls to CFFI simply
[GitHub] [qpid-dispatch] jiridanek merged pull request #1169: NO-JIRA: Skip the GHA Docs job until Proton 0.34.0 Ubuntu package is published
jiridanek merged pull request #1169: URL: https://github.com/apache/qpid-dispatch/pull/1169 -- 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. 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
