[jira] [Commented] (PROTON-2775) pn_buffer_ensure crash due to overflow
[
https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784528#comment-17784528
]
Ken Giusti commented on PROTON-2775:
Added a check of the computed capacity and an abort() call - the crash is
happening in pn_do_transfer (see attached proton-2775-2.txt). I'm not sure how
the application will be able to prevent that.
> pn_buffer_ensure crash due to overflow
> --
>
> Key: PROTON-2775
> URL: https://issues.apache.org/jira/browse/PROTON-2775
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.40.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: proton-2775-2.txt, proton-2775.txt
>
>
> pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
> _buf_ to hold at least {_}size{_}.
> The implementation of pn_buffer_t maintains a capacity field that represents
> the size of of the allocated memory buffer. This capacity is implemented as a
> uint32_t type.
> The issue is that pn_buffer_ensure does not check for buffer wrap within the
> uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
> can result in memory overflow and a crash.
> Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t
> is wrong. I totally agree that even that size is probably overkill.
> However I think the problem is that an application can trigger the wrap since
> there is no visibility to current capacity value with the current proton API.
> E.g. aggressively call pn_link_send() when the output network connection is
> blocked by a stalled receiver.
> At a minimum proton should detect an overflow event and not blindly double
> the capacity if the requested size is within the 32 bit range.
> I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
> size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
> attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2775) pn_buffer_ensure crash due to overflow
[
https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated PROTON-2775:
---
Attachment: proton-2775-2.txt
> pn_buffer_ensure crash due to overflow
> --
>
> Key: PROTON-2775
> URL: https://issues.apache.org/jira/browse/PROTON-2775
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.40.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: proton-2775-2.txt, proton-2775.txt
>
>
> pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
> _buf_ to hold at least {_}size{_}.
> The implementation of pn_buffer_t maintains a capacity field that represents
> the size of of the allocated memory buffer. This capacity is implemented as a
> uint32_t type.
> The issue is that pn_buffer_ensure does not check for buffer wrap within the
> uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
> can result in memory overflow and a crash.
> Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t
> is wrong. I totally agree that even that size is probably overkill.
> However I think the problem is that an application can trigger the wrap since
> there is no visibility to current capacity value with the current proton API.
> E.g. aggressively call pn_link_send() when the output network connection is
> blocked by a stalled receiver.
> At a minimum proton should detect an overflow event and not blindly double
> the capacity if the requested size is within the 32 bit range.
> I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
> size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
> attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2775) pn_buffer_ensure crash due to overflow
[
https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784512#comment-17784512
]
Ken Giusti commented on PROTON-2775:
Attachment proton-2775.txt contains a gdb stack dump of a crash due to
overflowed pn_buffer_t in delivery instance.
> pn_buffer_ensure crash due to overflow
> --
>
> Key: PROTON-2775
> URL: https://issues.apache.org/jira/browse/PROTON-2775
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.40.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: proton-2775.txt
>
>
> pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
> _buf_ to hold at least {_}size{_}.
> The implementation of pn_buffer_t maintains a capacity field that represents
> the size of of the allocated memory buffer. This capacity is implemented as a
> uint32_t type.
> The issue is that pn_buffer_ensure does not check for buffer wrap within the
> uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
> can result in memory overflow and a crash.
> Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t
> is wrong. I totally agree that even that size is probably overkill.
> However I think the problem is that an application can trigger the wrap since
> there is no visibility to current capacity value with the current proton API.
> E.g. aggressively call pn_link_send() when the output network connection is
> blocked by a stalled receiver.
> At a minimum proton should detect an overflow event and not blindly double
> the capacity if the requested size is within the 32 bit range.
> I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
> size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
> attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2775) pn_buffer_ensure crash due to overflow
[
https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated PROTON-2775:
---
Attachment: proton-2775.txt
> pn_buffer_ensure crash due to overflow
> --
>
> Key: PROTON-2775
> URL: https://issues.apache.org/jira/browse/PROTON-2775
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.40.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: proton-2775.txt
>
>
> pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
> _buf_ to hold at least {_}size{_}.
> The implementation of pn_buffer_t maintains a capacity field that represents
> the size of of the allocated memory buffer. This capacity is implemented as a
> uint32_t type.
> The issue is that pn_buffer_ensure does not check for buffer wrap within the
> uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
> can result in memory overflow and a crash.
> Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t
> is wrong. I totally agree that even that size is probably overkill.
> However I think the problem is that an application can trigger the wrap since
> there is no visibility to current capacity value with the current proton API.
> E.g. aggressively call pn_link_send() when the output network connection is
> blocked by a stalled receiver.
> At a minimum proton should detect an overflow event and not blindly double
> the capacity if the requested size is within the 32 bit range.
> I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
> size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
> attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2775) pn_buffer_ensure crash due to overflow
Ken Giusti created PROTON-2775:
--
Summary: pn_buffer_ensure crash due to overflow
Key: PROTON-2775
URL: https://issues.apache.org/jira/browse/PROTON-2775
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.40.0
Reporter: Ken Giusti
pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
_buf_ to hold at least {_}size{_}.
The implementation of pn_buffer_t maintains a capacity field that represents
the size of of the allocated memory buffer. This capacity is implemented as a
uint32_t type.
The issue is that pn_buffer_ensure does not check for buffer wrap within the
uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
can result in memory overflow and a crash.
Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t is
wrong. I totally agree that even that size is probably overkill.
However I think the problem is that an application can trigger the wrap since
there is no visibility to current capacity value with the current proton API.
E.g. aggressively call pn_link_send() when the output network connection is
blocked by a stalled receiver.
At a minimum proton should detect an overflow event and not blindly double the
capacity if the requested size is within the 32 bit range.
I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2742) The python binding installation instructions in python/PACKAGING.txt are wrong
[ https://issues.apache.org/jira/browse/PROTON-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-2742: --- Description: The python/PACKAGING.txt file should probably just be deleted. The top-level INSTALL.md file contains the correct installation instructions. > The python binding installation instructions in python/PACKAGING.txt are wrong > -- > > Key: PROTON-2742 > URL: https://issues.apache.org/jira/browse/PROTON-2742 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Ken Giusti >Priority: Trivial > > The python/PACKAGING.txt file should probably just be deleted. The top-level > INSTALL.md file contains the correct installation instructions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2742) The python binding installation instructions in python/PACKAGING.txt are wrong
Ken Giusti created PROTON-2742: -- Summary: The python binding installation instructions in python/PACKAGING.txt are wrong Key: PROTON-2742 URL: https://issues.apache.org/jira/browse/PROTON-2742 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Ken Giusti -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2354) Compilation failure on Fedora 38
[
https://issues.apache.org/jira/browse/DISPATCH-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned DISPATCH-2354:
Assignee: Ken Giusti
> Compilation failure on Fedora 38
>
>
> Key: DISPATCH-2354
> URL: https://issues.apache.org/jira/browse/DISPATCH-2354
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
>
> {noformat}
> In file included from
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:27:
> In function 'qd_buffer_list_append_field',
> inlined from 'compose_router_message_annotations' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1821:13,
> inlined from 'qd_message_send' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1905:33:
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/buffer_field_api.h:284:27:
> error: 'in_trace.remaining' may be used uninitialized
> [-Werror=maybe-uninitialized]
> 284 | bfield->remaining -= len;
> | ^~
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c: In function
> 'qd_message_send':
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1806:27: note:
> 'in_trace.remaining' was declared here
> 1806 | qd_buffer_field_t in_trace;
> | ^~~~
> In file included from
> /builddir/build/BUILD/qpid-dispatch-1.19.0/include/qpid/dispatch/message.h:22,
> from
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:20:
> In function 'qd_buffer_cursor',
> inlined from 'qd_buffer_list_append_field' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/buffer_field_api.h:280:24,
> inlined from 'compose_router_message_annotations' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1821:13,
> inlined from 'qd_message_send' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1905:33:
> /builddir/build/BUILD/qpid-dispatch-1.19.0/include/qpid/dispatch/buffer.h:83:39:
> error: 'in_trace.buffer' may be used uninitialized
> [-Werror=maybe-uninitialized]
>83 | return ((unsigned char*) [1]) + buf->size;
> |~~~^~~
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c: In function
> 'qd_message_send':
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1806:27: note:
> 'in_trace.buffer' was declared here
> 1806 | qd_buffer_field_t in_trace;
> | ^~~~
> In function 'qd_buffer_list_append_field',
> inlined from 'compose_router_message_annotations' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1821:13,
> inlined from 'qd_message_send' at
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1905:33:
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/buffer_field_api.h:280:57:
> error: 'in_trace.cursor' may be used uninitialized
> [-Werror=maybe-uninitialized]
> 280 | size_t avail = qd_buffer_cursor(bfield->buffer) -
> bfield->cursor;
> |
> ~^~~~
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c: In function
> 'qd_message_send':
> /builddir/build/BUILD/qpid-dispatch-1.19.0/src/message.c:1806:27: note:
> 'in_trace.cursor' was declared here
> 1806 | qd_buffer_field_t in_trace;
> | ^~~~
> cc1: all warnings being treated as errors
> make[2]: *** [src/CMakeFiles/qpid-dispatch.dir/build.make:405:
> src/CMakeFiles/qpid-dispatch.dir/message.c.o] Error 1
> make[2]: Leaving directory '/builddir/build/BUILD/qpid-dispatch-1.19.0'
> make[1]: *** [CMakeFiles/Makefile2:1030:
> src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make[1]: Leaving directory '/builddir/build/BUILD/qpid-dispatch-1.19.0'
> make: *** [Makefile:149: all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.XW4Weo (%build)
> RPM build warnings:
> RPM build errors:
> line 56: It's not recommended to have unversioned Obsoletes: Obsoletes:
> libqpid-dispatch
> line 57: It's not recommended to have unversioned Obsoletes: Obsoletes:
> libqpid-dispatch-devel
> line 110: It's not recommended to have unversioned Obsoletes: Obsoletes:
> qpid-dispatch-router-docs
> Bad exit status from /var/tmp/rpm-tmp.XW4Weo (%build)
> Child return code was: 1
> EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M
> 59981b45e3a84010bd25b5df4ad8b522 -D
> /var/lib/mock/f39-build-41300068-5058376/root -a -u mockbuild
> --capability=cap_ipc_lock --bind=/tmp/mock-resolv.uytbst9d:/etc/resolv.conf
> --bind=/dev/btrfs-control --bind=/dev/mapper/control --bind=/dev/loop-control
> --bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2
[jira] [Assigned] (PROTON-2680) [proton-c] PN_RAW_CONNECTION_DISCONNECTED event does not show up when client is disconnected
[
https://issues.apache.org/jira/browse/PROTON-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned PROTON-2680:
--
Assignee: Clifford Jansen (was: Ken Giusti)
> [proton-c] PN_RAW_CONNECTION_DISCONNECTED event does not show up when client
> is disconnected
> -
>
> Key: PROTON-2680
> URL: https://issues.apache.org/jira/browse/PROTON-2680
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Ganesh Murthy
>Assignee: Clifford Jansen
>Priority: Major
>
> Steps to reproduce
> Start the skupper-router with the following config -
> {noformat}
> router {
> mode: standalone
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> tcpConnector {
> name: echo-1
> host: 10.108.50.177
> port: 9090
> address: echo
> }
> tcpConnector {
> name: echo-2
> host: 10.108.50.177
> port: 9090
> address: echo
> }
> tcpListener {
> host: 0.0.0.0
> port: 9000
> address: echo
> }
> log {
> module: DEFAULT
> enable: trace+
> outputFile: tcp.log
> } {noformat}
>
> Note that the ip address in the host field of the tcpConnector is bogus.
> Now connect a curl client to the tcpListener port -
> {noformat}
> curl http://localhost:9000/api {noformat}
>
> The curl client will hang. Terminate the curl client and look in the tcp.log
> for logged proton events - the PN_RAW_CONNECTION_DISCONNECTED event will be
> missing on connection C2
> Here is the full log of the relevant client connection
>
> {noformat}
> 2023-02-01 16:51:57.069705 -0500 ROUTER_CORE (info) [C2] Connection Opened:
> dir=in host=127.0.0.1:35348 encrypted=no auth=no user=
> container_id=TcpAdaptor props={:"qd.adaptor"="tcp"}
> 2023-02-01 16:51:57.069793 -0500 ROUTER_CORE (trace) Core action
> 'connection_opened'
> 2023-02-01 16:51:57.069986 -0500 TCP_ADAPTOR (info) [C2]
> PN_RAW_CONNECTION_CONNECTED Listener ingress accepted to 0.0.0.0:9000 from
> 127.0.0.1:35348 (global_id=127.0.0.1:35348)
> 2023-02-01 16:51:57.070015 -0500 ROUTER_CORE (trace) Core action
> 'link_first_attach'
> 2023-02-01 16:51:57.070098 -0500 TCP_ADAPTOR (debug) [C2]
> PN_RAW_CONNECTION_NEED_WRITE_BUFFERS listener
> 2023-02-01 16:51:57.070148 -0500 TCP_ADAPTOR (debug) [C2]
> PN_RAW_CONNECTION_NEED_READ_BUFFERS listener
> 2023-02-01 16:51:57.070171 -0500 ROUTER_CORE (info) [C2][L4] Link attached:
> dir=out source={(dyn) expire:link} target={ expire:link}
> 2023-02-01 16:51:57.070222 -0500 TCP_ADAPTOR (debug) [C2]
> qdr_tcp_activate_CT: call pn_raw_connection_wake()
> 2023-02-01 16:51:57.070246 -0500 ROUTER_CORE (trace) Core action
> 'link_first_attach'
> 2023-02-01 16:51:57.070273 -0500 TCP_ADAPTOR (debug) [C2][L4] (listener
> outgoing) qdr_tcp_second_attach
> 2023-02-01 16:51:57.070347 -0500 DEFAULT (trace) Parse tree search for 'echo'
> 2023-02-01 16:51:57.070376 -0500 TCP_ADAPTOR (trace) [C2][L5] handle_incoming
> qdr_tcp_second_attach for listener connection. read_closed:F, flow_enabled:F
> 2023-02-01 16:51:57.070404 -0500 DEFAULT (trace) Parse tree match not found
> 2023-02-01 16:51:57.070425 -0500 TCP_ADAPTOR (debug) [C2][L5] Waiting for
> credit before initiating listener ingress stream message, returning
> 2023-02-01 16:51:57.070456 -0500 TCP_ADAPTOR (debug) [C2][L4]
> qdr_tcp_get_credit: NOOP
> 2023-02-01 16:51:57.070517 -0500 TCP_ADAPTOR (trace) Listener
> tcpListener/0.0.0.0:9000 (0.0.0.0:9000) service address echo consumer count
> updates: local=1 in-process=0 remote=0
> 2023-02-01 16:51:57.070553 -0500 ROUTER_CORE (info) [C2][L5] Link attached:
> dir=in source={ expire:link} target={echo expire:link}
> 2023-02-01 16:51:57.070583 -0500 ROUTER_CORE (trace) Core action
> 'add_tcp_connection'
> 2023-02-01 16:51:57.070606 -0500 TCP_ADAPTOR (debug) [C2]
> PN_RAW_CONNECTION_WAKE listener
> 2023-02-01 16:51:57.070646 -0500 TCP_ADAPTOR (debug) [C2]
> qdr_add_tcp_connection_CT 0.0.0.0:9000 (1)
> 2023-02-01 16:51:57.070673 -0500 TCP_ADAPTOR (debug) [C2][L4] qdr_tcp_flow:
> Flow enabled, credit=250
> 2023-02-01 16:51:57.070722 -0500 TCP_ADAPTOR (debug) [C2]
> qdr_tcp_activate_CT: call pn_raw_connection_wake()
> 2023-02-01 16:51:57.070774 -0500 ROUTER_CORE (trace) Core action 'link_flow'
> 2023-02-01 16:51:57.070800 -0500 TCP_ADAPTOR (trace) [C2][L5] handle_incoming
> qdr_tcp_flow for listener connection. read_closed:F, flow_enabled:T
> 2023-02-01 16:51:57.070831 -0500 TCP_ADAPTOR (debug) [C2]
> handle_incoming_raw_read() returning with result=0
> 2023-02-01 16:51:57.071258 -0500 TCP_ADAPTOR (debug) [C2][L5] Initiating
> listener (ingress) stream incoming link for listener connection to: echo
> reply: amqp:/_topo/0/QDR.A/temp.rr__pKcuMowq3o4
>
[jira] [Assigned] (PROTON-2684) CFFI related TypeError: '%x format: an integer is required, not _cffi_backend._CDataBase'
[
https://issues.apache.org/jira/browse/PROTON-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned PROTON-2684:
--
Assignee: Andrew Stitcher
> CFFI related TypeError: '%x format: an integer is required, not
> _cffi_backend._CDataBase'
> --
>
> Key: PROTON-2684
> URL: https://issues.apache.org/jira/browse/PROTON-2684
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
>
> Hit in skupper-router CI test:
>
>
> {code:java}
> 36: self = object at 0x7fc9b9d5d550>
> 36: event = <[TypeError('%x format: an integer is required, not
> _cffi_backend._CDataBase') raised in repr()] Event object at 0x7fc9b9d76a90>
> {code}
>
>
> [https://github.com/skupperproject/skupper-router/actions/runs/4176741670/jobs/7233430902#step:30:847]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2684) CFFI related TypeError: '%x format: an integer is required, not _cffi_backend._CDataBase'
Ken Giusti created PROTON-2684:
--
Summary: CFFI related TypeError: '%x format: an integer is
required, not _cffi_backend._CDataBase'
Key: PROTON-2684
URL: https://issues.apache.org/jira/browse/PROTON-2684
Project: Qpid Proton
Issue Type: Bug
Reporter: Ken Giusti
Hit in skupper-router CI test:
{code:java}
36: self =
36: event = <[TypeError('%x format: an integer is required, not
_cffi_backend._CDataBase') raised in repr()] Event object at 0x7fc9b9d76a90>
{code}
[https://github.com/skupperproject/skupper-router/actions/runs/4176741670/jobs/7233430902#step:30:847]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2680) [proton-c] PN_RAW_CONNECTION_DISCONNECTED event does not show up when client is disconnected
[
https://issues.apache.org/jira/browse/PROTON-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned PROTON-2680:
--
Assignee: Ken Giusti
> [proton-c] PN_RAW_CONNECTION_DISCONNECTED event does not show up when client
> is disconnected
> -
>
> Key: PROTON-2680
> URL: https://issues.apache.org/jira/browse/PROTON-2680
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
>
> Steps to reproduce
> Start the skupper-router with the following config -
> {noformat}
> router {
> mode: standalone
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> tcpConnector {
> name: echo-1
> host: 10.108.50.177
> port: 9090
> address: echo
> }
> tcpConnector {
> name: echo-2
> host: 10.108.50.177
> port: 9090
> address: echo
> }
> tcpListener {
> host: 0.0.0.0
> port: 9000
> address: echo
> }
> log {
> module: DEFAULT
> enable: trace+
> outputFile: tcp.log
> } {noformat}
>
> Note that the ip address in the host field of the tcpConnector is bogus.
> Now connect a curl client to the tcpListener port -
> {noformat}
> curl http://localhost:9000/api {noformat}
>
> The curl client will hang. Terminate the curl client and look in the tcp.log
> for logged proton events - the PN_RAW_CONNECTION_DISCONNECTED event will be
> missing on connection C2
> Here is the full log of the relevant client connection
>
> {noformat}
> 2023-02-01 16:51:57.069705 -0500 ROUTER_CORE (info) [C2] Connection Opened:
> dir=in host=127.0.0.1:35348 encrypted=no auth=no user=
> container_id=TcpAdaptor props={:"qd.adaptor"="tcp"}
> 2023-02-01 16:51:57.069793 -0500 ROUTER_CORE (trace) Core action
> 'connection_opened'
> 2023-02-01 16:51:57.069986 -0500 TCP_ADAPTOR (info) [C2]
> PN_RAW_CONNECTION_CONNECTED Listener ingress accepted to 0.0.0.0:9000 from
> 127.0.0.1:35348 (global_id=127.0.0.1:35348)
> 2023-02-01 16:51:57.070015 -0500 ROUTER_CORE (trace) Core action
> 'link_first_attach'
> 2023-02-01 16:51:57.070098 -0500 TCP_ADAPTOR (debug) [C2]
> PN_RAW_CONNECTION_NEED_WRITE_BUFFERS listener
> 2023-02-01 16:51:57.070148 -0500 TCP_ADAPTOR (debug) [C2]
> PN_RAW_CONNECTION_NEED_READ_BUFFERS listener
> 2023-02-01 16:51:57.070171 -0500 ROUTER_CORE (info) [C2][L4] Link attached:
> dir=out source={(dyn) expire:link} target={ expire:link}
> 2023-02-01 16:51:57.070222 -0500 TCP_ADAPTOR (debug) [C2]
> qdr_tcp_activate_CT: call pn_raw_connection_wake()
> 2023-02-01 16:51:57.070246 -0500 ROUTER_CORE (trace) Core action
> 'link_first_attach'
> 2023-02-01 16:51:57.070273 -0500 TCP_ADAPTOR (debug) [C2][L4] (listener
> outgoing) qdr_tcp_second_attach
> 2023-02-01 16:51:57.070347 -0500 DEFAULT (trace) Parse tree search for 'echo'
> 2023-02-01 16:51:57.070376 -0500 TCP_ADAPTOR (trace) [C2][L5] handle_incoming
> qdr_tcp_second_attach for listener connection. read_closed:F, flow_enabled:F
> 2023-02-01 16:51:57.070404 -0500 DEFAULT (trace) Parse tree match not found
> 2023-02-01 16:51:57.070425 -0500 TCP_ADAPTOR (debug) [C2][L5] Waiting for
> credit before initiating listener ingress stream message, returning
> 2023-02-01 16:51:57.070456 -0500 TCP_ADAPTOR (debug) [C2][L4]
> qdr_tcp_get_credit: NOOP
> 2023-02-01 16:51:57.070517 -0500 TCP_ADAPTOR (trace) Listener
> tcpListener/0.0.0.0:9000 (0.0.0.0:9000) service address echo consumer count
> updates: local=1 in-process=0 remote=0
> 2023-02-01 16:51:57.070553 -0500 ROUTER_CORE (info) [C2][L5] Link attached:
> dir=in source={ expire:link} target={echo expire:link}
> 2023-02-01 16:51:57.070583 -0500 ROUTER_CORE (trace) Core action
> 'add_tcp_connection'
> 2023-02-01 16:51:57.070606 -0500 TCP_ADAPTOR (debug) [C2]
> PN_RAW_CONNECTION_WAKE listener
> 2023-02-01 16:51:57.070646 -0500 TCP_ADAPTOR (debug) [C2]
> qdr_add_tcp_connection_CT 0.0.0.0:9000 (1)
> 2023-02-01 16:51:57.070673 -0500 TCP_ADAPTOR (debug) [C2][L4] qdr_tcp_flow:
> Flow enabled, credit=250
> 2023-02-01 16:51:57.070722 -0500 TCP_ADAPTOR (debug) [C2]
> qdr_tcp_activate_CT: call pn_raw_connection_wake()
> 2023-02-01 16:51:57.070774 -0500 ROUTER_CORE (trace) Core action 'link_flow'
> 2023-02-01 16:51:57.070800 -0500 TCP_ADAPTOR (trace) [C2][L5] handle_incoming
> qdr_tcp_flow for listener connection. read_closed:F, flow_enabled:T
> 2023-02-01 16:51:57.070831 -0500 TCP_ADAPTOR (debug) [C2]
> handle_incoming_raw_read() returning with result=0
> 2023-02-01 16:51:57.071258 -0500 TCP_ADAPTOR (debug) [C2][L5] Initiating
> listener (ingress) stream incoming link for listener connection to: echo
> reply: amqp:/_topo/0/QDR.A/temp.rr__pKcuMowq3o4
> 2023-02-01 16:51:57.071468 -0500
[jira] [Assigned] (PROTON-2679) Parallel build of python bindings occasionally fails
[ https://issues.apache.org/jira/browse/PROTON-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-2679: -- Assignee: Andrew Stitcher > Parallel build of python bindings occasionally fails > > > Key: PROTON-2679 > URL: https://issues.apache.org/jira/browse/PROTON-2679 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.39.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Major > > See skupper CI failure: > [https://github.com/skupperproject/skupper-router/actions/runs/4056555498/jobs/6981190135#step:17:234] > Appears to be trying to build the same file twice: > > cd /__w/skupper-router/skupper-router/qpid-proton/build/python && > /usr/bin/cmake -E copy > /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_condition.py > proton/_condition.py > > [ 38%] Generating proton/_condition.py > > cd /__w/skupper-router/skupper-router/qpid-proton/build/python && > /usr/bin/cmake -E copy > /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_condition.py > proton/_condition.py > > [ 39%] Generating proton/_data.py > > cd /__w/skupper-router/skupper-router/qpid-proton/build/python && > /usr/bin/cmake -E copy > /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_data.py > proton/_data.py > > [ 40%] Generating proton/_data.py > > cd /__w/skupper-router/skupper-router/qpid-proton/build/python && > /usr/bin/cmake -E copy > /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_data.py > proton/_data.py > > Error copying file > "/home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_condition.py" > to "proton/_condition.py". > > gmake[2]: *** [python/CMakeFiles/pydist.dir/build.make:280: > python/proton/_condition.py] Error 1 > > gmake[2]: *** Deleting file 'python/proton/_condition.py' > > gmake[2]: *** Waiting for unfinished jobs > > gmake[1]: *** [CMakeFiles/Makefile2:572: python/CMakeFiles/pydist.dir/all] > Error 2 > > gmake[2]: Leaving directory > '/__w/skupper-router/skupper-router/qpid-proton/build' > > gmake[1]: *** Waiting for unfinished jobs -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2679) Parallel build of python bindings occasionally fails
Ken Giusti created PROTON-2679: -- Summary: Parallel build of python bindings occasionally fails Key: PROTON-2679 URL: https://issues.apache.org/jira/browse/PROTON-2679 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: proton-c-0.39.0 Reporter: Ken Giusti See skupper CI failure: [https://github.com/skupperproject/skupper-router/actions/runs/4056555498/jobs/6981190135#step:17:234] Appears to be trying to build the same file twice: cd /__w/skupper-router/skupper-router/qpid-proton/build/python && /usr/bin/cmake -E copy /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_condition.py proton/_condition.py [ 38%] Generating proton/_condition.py cd /__w/skupper-router/skupper-router/qpid-proton/build/python && /usr/bin/cmake -E copy /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_condition.py proton/_condition.py [ 39%] Generating proton/_data.py cd /__w/skupper-router/skupper-router/qpid-proton/build/python && /usr/bin/cmake -E copy /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_data.py proton/_data.py [ 40%] Generating proton/_data.py cd /__w/skupper-router/skupper-router/qpid-proton/build/python && /usr/bin/cmake -E copy /home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_data.py proton/_data.py Error copying file "/home/runner/work/skupper-router/skupper-router/qpid-proton/python/proton/_condition.py" to "proton/_condition.py". gmake[2]: *** [python/CMakeFiles/pydist.dir/build.make:280: python/proton/_condition.py] Error 1 gmake[2]: *** Deleting file 'python/proton/_condition.py' gmake[2]: *** Waiting for unfinished jobs gmake[1]: *** [CMakeFiles/Makefile2:572: python/CMakeFiles/pydist.dir/all] Error 2 gmake[2]: Leaving directory '/__w/skupper-router/skupper-router/qpid-proton/build' gmake[1]: *** Waiting for unfinished jobs -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2673) Proactor hangs if pn_raw_connection_wake() is called with outstanding connection attempt
[
https://issues.apache.org/jira/browse/PROTON-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated PROTON-2673:
---
Description:
If pn_raw_connection_wake() is called on a raw connection that is attempting to
connect no further proactor events are generated and the proactor hangs.
Important observations:
* This only occurs {_}if there is no server available at the target address
for the connection{_}. If a server is present then the PN_RAW_CONNECTION_WAKE
and PN_RAW_CONNECTION_CONNECTED events arrive properly (in that order).
* The host address is "localhost" - using "127.0.0.1" or "::1" instead works.
localhost on my machine maps to both "127.0.0.1" and "::1"
* Extra bonus: if you move the call to pn_raw_connection_wake() to _before_
the call to pn_proactor_raw_connect() a crash occurs
See attached reproducer.
was:
If pn_raw_connection_wake() is called on a raw connection that is attempting to
connect no further proactor events are generated and the proactor hangs.
Important observations:
* This only occurs {_}if there is no server available at the target address
for the connection{_}. If a server is present then the PN_RAW_CONNECTION_WAKE
and PN_RAW_CONNECTION_CONNECTED events arrive properly (in that order).
* The host address is "localhost" - using "127.0.0.1" works. localhost on my
machine maps to both "127.0.0.1" and "::1"
* Extra bonus: if you move the call to pn_raw_connection_wake() to _before_
the call to pn_proactor_raw_connect() a crash occurs
See attached reproducer.
> Proactor hangs if pn_raw_connection_wake() is called with outstanding
> connection attempt
>
>
> Key: PROTON-2673
> URL: https://issues.apache.org/jira/browse/PROTON-2673
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.38.0, proton-c-0.39.0
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
> Attachments: raw_wake.c
>
>
> If pn_raw_connection_wake() is called on a raw connection that is attempting
> to connect no further proactor events are generated and the proactor hangs.
> Important observations:
> * This only occurs {_}if there is no server available at the target address
> for the connection{_}. If a server is present then the PN_RAW_CONNECTION_WAKE
> and PN_RAW_CONNECTION_CONNECTED events arrive properly (in that order).
> * The host address is "localhost" - using "127.0.0.1" or "::1" instead
> works. localhost on my machine maps to both "127.0.0.1" and "::1"
> * Extra bonus: if you move the call to pn_raw_connection_wake() to _before_
> the call to pn_proactor_raw_connect() a crash occurs
> See attached reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2673) Proactor hangs if pn_raw_connection_wake() is called with outstanding connection attempt
[
https://issues.apache.org/jira/browse/PROTON-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned PROTON-2673:
--
Assignee: Andrew Stitcher
> Proactor hangs if pn_raw_connection_wake() is called with outstanding
> connection attempt
>
>
> Key: PROTON-2673
> URL: https://issues.apache.org/jira/browse/PROTON-2673
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.38.0, proton-c-0.39.0
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
> Attachments: raw_wake.c
>
>
> If pn_raw_connection_wake() is called on a raw connection that is attempting
> to connect no further proactor events are generated and the proactor hangs.
> Important observations:
> * This only occurs {_}if there is no server available at the target address
> for the connection{_}. If a server is present then the PN_RAW_CONNECTION_WAKE
> and PN_RAW_CONNECTION_CONNECTED events arrive properly (in that order).
> * The host address is "localhost" - using "127.0.0.1" works. localhost on my
> machine maps to both "127.0.0.1" and "::1"
> * Extra bonus: if you move the call to pn_raw_connection_wake() to _before_
> the call to pn_proactor_raw_connect() a crash occurs
> See attached reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2673) Proactor hangs if pn_raw_connection_wake() is called with outstanding connection attempt
Ken Giusti created PROTON-2673:
--
Summary: Proactor hangs if pn_raw_connection_wake() is called with
outstanding connection attempt
Key: PROTON-2673
URL: https://issues.apache.org/jira/browse/PROTON-2673
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.38.0, proton-c-0.39.0
Reporter: Ken Giusti
Attachments: raw_wake.c
If pn_raw_connection_wake() is called on a raw connection that is attempting to
connect no further proactor events are generated and the proactor hangs.
Important observations:
* This only occurs {_}if there is no server available at the target address
for the connection{_}. If a server is present then the PN_RAW_CONNECTION_WAKE
and PN_RAW_CONNECTION_CONNECTED events arrive properly (in that order).
* The host address is "localhost" - using "127.0.0.1" works. localhost on my
machine maps to both "127.0.0.1" and "::1"
* Extra bonus: if you move the call to pn_raw_connection_wake() to _before_
the call to pn_proactor_raw_connect() a crash occurs
See attached reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2622) TLS OpenSSL library: ensure capacity values match given capacity
[ https://issues.apache.org/jira/browse/PROTON-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-2622: -- Assignee: Clifford Jansen > TLS OpenSSL library: ensure capacity values match given capacity > > > Key: PROTON-2622 > URL: https://issues.apache.org/jira/browse/PROTON-2622 > Project: Qpid Proton > Issue Type: Wish > Components: proton-c >Affects Versions: proton-c-0.38.0 >Reporter: Ken Giusti >Assignee: Clifford Jansen >Priority: Major > > pn_tls_get_encrypt/decrypt_input_buffer_capacity() unconditionally return > the number of empty buffer slots. > However pn_tls_give_encrypt/decrypt_input_buffers() checks the state of the > tls session and can take zero buffers even though get capacity returned > 0. > In this case the application will have to "unwind" any buffer > allocation/setup work it did expecting there was capacity available. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2622) TLS OpenSSL library: ensure capacity values match given capacity
[ https://issues.apache.org/jira/browse/PROTON-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616059#comment-17616059 ] Ken Giusti commented on PROTON-2622: Pull Request https://github.com/apache/qpid-proton/pull/380 > TLS OpenSSL library: ensure capacity values match given capacity > > > Key: PROTON-2622 > URL: https://issues.apache.org/jira/browse/PROTON-2622 > Project: Qpid Proton > Issue Type: Wish > Components: proton-c >Affects Versions: proton-c-0.38.0 >Reporter: Ken Giusti >Priority: Major > > pn_tls_get_encrypt/decrypt_input_buffer_capacity() unconditionally return > the number of empty buffer slots. > However pn_tls_give_encrypt/decrypt_input_buffers() checks the state of the > tls session and can take zero buffers even though get capacity returned > 0. > In this case the application will have to "unwind" any buffer > allocation/setup work it did expecting there was capacity available. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2622) TLS OpenSSL library: ensure capacity values match given capacity
Ken Giusti created PROTON-2622: -- Summary: TLS OpenSSL library: ensure capacity values match given capacity Key: PROTON-2622 URL: https://issues.apache.org/jira/browse/PROTON-2622 Project: Qpid Proton Issue Type: Wish Components: proton-c Affects Versions: proton-c-0.38.0 Reporter: Ken Giusti pn_tls_get_encrypt/decrypt_input_buffer_capacity() unconditionally return the number of empty buffer slots. However pn_tls_give_encrypt/decrypt_input_buffers() checks the state of the tls session and can take zero buffers even though get capacity returned > 0. In this case the application will have to "unwind" any buffer allocation/setup work it did expecting there was capacity available. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2568) Leak of addrinfo memory held by raw connection
[ https://issues.apache.org/jira/browse/PROTON-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-2568: -- Assignee: Andrew Stitcher > Leak of addrinfo memory held by raw connection > --- > > Key: PROTON-2568 > URL: https://issues.apache.org/jira/browse/PROTON-2568 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.37.0, proton-c-0.38.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Major > Attachments: fix.patch > > > This leak can be triggered by running the skupper-router http1 unit test for > a single router, example: > /usr/bin/python3.10 > "/home/kgiusti/work/skupper/skupper-router/BUILD/tests/run.py" "-m" > "unittest" "-v" > "system_tests_http1_adaptor.Http1AdaptorOneRouterTest.test_001_get" > > The leak occurs when skupper-router is attempting to connect to a remote HTTP > server via a raw connection but shuts down before any raw connection events > are processed (e.g. No PN_RAW_CONNECTION_CONNECTED or _DISCONNECTED). > During shutdown the router frees the proactor and expects any outstanding raw > connection resources owned by it to be freed. > I've traced the proactor shutdown logic, and when the leak occurs there is a > final call to praw_connection_cleanup() for the outstanding connection, but > the praw_connection_t still holds a pointer to the allocated addrinfo. > praw_connection_cleanup() frees the praw_connection_t but does not call > freeaddrinfo(prc->addrinfo) to release the addrinfo memory. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2568) Leak of addrinfo memory held by raw connection
[ https://issues.apache.org/jira/browse/PROTON-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556953#comment-17556953 ] Ken Giusti commented on PROTON-2568: Added example fix. > Leak of addrinfo memory held by raw connection > --- > > Key: PROTON-2568 > URL: https://issues.apache.org/jira/browse/PROTON-2568 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.37.0, proton-c-0.38.0 >Reporter: Ken Giusti >Priority: Major > Attachments: fix.patch > > > This leak can be triggered by running the skupper-router http1 unit test for > a single router, example: > /usr/bin/python3.10 > "/home/kgiusti/work/skupper/skupper-router/BUILD/tests/run.py" "-m" > "unittest" "-v" > "system_tests_http1_adaptor.Http1AdaptorOneRouterTest.test_001_get" > > The leak occurs when skupper-router is attempting to connect to a remote HTTP > server via a raw connection but shuts down before any raw connection events > are processed (e.g. No PN_RAW_CONNECTION_CONNECTED or _DISCONNECTED). > During shutdown the router frees the proactor and expects any outstanding raw > connection resources owned by it to be freed. > I've traced the proactor shutdown logic, and when the leak occurs there is a > final call to praw_connection_cleanup() for the outstanding connection, but > the praw_connection_t still holds a pointer to the allocated addrinfo. > praw_connection_cleanup() frees the praw_connection_t but does not call > freeaddrinfo(prc->addrinfo) to release the addrinfo memory. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2568) Leak of addrinfo memory held by raw connection
[ https://issues.apache.org/jira/browse/PROTON-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-2568: --- Attachment: fix.patch > Leak of addrinfo memory held by raw connection > --- > > Key: PROTON-2568 > URL: https://issues.apache.org/jira/browse/PROTON-2568 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.37.0, proton-c-0.38.0 >Reporter: Ken Giusti >Priority: Major > Attachments: fix.patch > > > This leak can be triggered by running the skupper-router http1 unit test for > a single router, example: > /usr/bin/python3.10 > "/home/kgiusti/work/skupper/skupper-router/BUILD/tests/run.py" "-m" > "unittest" "-v" > "system_tests_http1_adaptor.Http1AdaptorOneRouterTest.test_001_get" > > The leak occurs when skupper-router is attempting to connect to a remote HTTP > server via a raw connection but shuts down before any raw connection events > are processed (e.g. No PN_RAW_CONNECTION_CONNECTED or _DISCONNECTED). > During shutdown the router frees the proactor and expects any outstanding raw > connection resources owned by it to be freed. > I've traced the proactor shutdown logic, and when the leak occurs there is a > final call to praw_connection_cleanup() for the outstanding connection, but > the praw_connection_t still holds a pointer to the allocated addrinfo. > praw_connection_cleanup() frees the praw_connection_t but does not call > freeaddrinfo(prc->addrinfo) to release the addrinfo memory. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2568) Leak of addrinfo memory held by raw connection
Ken Giusti created PROTON-2568: -- Summary: Leak of addrinfo memory held by raw connection Key: PROTON-2568 URL: https://issues.apache.org/jira/browse/PROTON-2568 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.37.0, proton-c-0.38.0 Reporter: Ken Giusti This leak can be triggered by running the skupper-router http1 unit test for a single router, example: /usr/bin/python3.10 "/home/kgiusti/work/skupper/skupper-router/BUILD/tests/run.py" "-m" "unittest" "-v" "system_tests_http1_adaptor.Http1AdaptorOneRouterTest.test_001_get" The leak occurs when skupper-router is attempting to connect to a remote HTTP server via a raw connection but shuts down before any raw connection events are processed (e.g. No PN_RAW_CONNECTION_CONNECTED or _DISCONNECTED). During shutdown the router frees the proactor and expects any outstanding raw connection resources owned by it to be freed. I've traced the proactor shutdown logic, and when the leak occurs there is a final call to praw_connection_cleanup() for the outstanding connection, but the praw_connection_t still holds a pointer to the allocated addrinfo. praw_connection_cleanup() frees the praw_connection_t but does not call freeaddrinfo(prc->addrinfo) to release the addrinfo memory. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2556) Remove all uses of pn_string and pn_list from example code
[ https://issues.apache.org/jira/browse/PROTON-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551621#comment-17551621 ] Ken Giusti commented on PROTON-2556: Any use of internal proton APIs by skupper-router or qpid-dispatch is a bug and needs to be resolved in those projects. That said I was under the impression that proton-internal APIs used the pni_* prefix - is that not the case? Ideally if these internal apis are available via the public headers (c/include/proton) they should be moved to an internal header file or use conditional compilation to prevent use by outside project (just my $0.02 USD) > Remove all uses of pn_string and pn_list from example code > -- > > Key: PROTON-2556 > URL: https://issues.apache.org/jira/browse/PROTON-2556 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > pn_string and pn_list are currently internal APIs and should not be used by > application programs. > The proton library is really not in the business of providing a data > structures library! -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2344) Mobile addresses out-of-sync on two routers in a network (skupper-router #473)
[ https://issues.apache.org/jira/browse/DISPATCH-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2344. -- Resolution: Fixed > Mobile addresses out-of-sync on two routers in a network (skupper-router > #473) > > > Key: DISPATCH-2344 > URL: https://issues.apache.org/jira/browse/DISPATCH-2344 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.19.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.20.0 > > > Backport fix from > [https://github.com/skupperproject/skupper-router/issues/473] > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2553) Hang in proactor thread waiting for PN_PROACTOR_INTERRUPT
[ https://issues.apache.org/jira/browse/PROTON-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-2553: -- Assignee: Clifford Jansen > Hang in proactor thread waiting for PN_PROACTOR_INTERRUPT > - > > Key: PROTON-2553 > URL: https://issues.apache.org/jira/browse/PROTON-2553 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.37.0 >Reporter: Ken Giusti >Assignee: Clifford Jansen >Priority: Major > > Recently changed (~2 weeks) the Skupper-router project's CI to help diagnose > very occasional timeout error that appear to be happening during router > shutdown. The CI test infrastructure now sends a SIGABORT to a router that > has not exited within 60 seconds of receiving a SIGTERM. > This resulted in a weird test failure - only captured once so far - that > appears as if the router is stuck in proactor. > See > [https://github.com/skupperproject/skupper-router/runs/6698510074#step:29:84] > for the gdb crash traceback. > And the related skupper-router issue: > [https://github.com/skupperproject/skupper-router/issues/535] > Unable to reproduce. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2553) Hang in proactor thread waiting for PN_PROACTOR_INTERRUPT
Ken Giusti created PROTON-2553: -- Summary: Hang in proactor thread waiting for PN_PROACTOR_INTERRUPT Key: PROTON-2553 URL: https://issues.apache.org/jira/browse/PROTON-2553 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.37.0 Reporter: Ken Giusti Recently changed (~2 weeks) the Skupper-router project's CI to help diagnose very occasional timeout error that appear to be happening during router shutdown. The CI test infrastructure now sends a SIGABORT to a router that has not exited within 60 seconds of receiving a SIGTERM. This resulted in a weird test failure - only captured once so far - that appears as if the router is stuck in proactor. See [https://github.com/skupperproject/skupper-router/runs/6698510074#step:29:84] for the gdb crash traceback. And the related skupper-router issue: [https://github.com/skupperproject/skupper-router/issues/535] Unable to reproduce. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2342) Remove use of deprecated proton-c reactor in tests (skupper issue #482)
[ https://issues.apache.org/jira/browse/DISPATCH-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2342. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;a=commit;h=5d693210b806f5441960a457c68f16fd3fc83606 > Remove use of deprecated proton-c reactor in tests (skupper issue #482) > --- > > Key: DISPATCH-2342 > URL: https://issues.apache.org/jira/browse/DISPATCH-2342 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.19.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.20.0 > > > Backport fix from skupper-router -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2342) Remove use of deprecated proton-c reactor in tests (skupper issue #482)
[ https://issues.apache.org/jira/browse/DISPATCH-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544429#comment-17544429 ] Ken Giusti commented on DISPATCH-2342: -- Closed - forgot to add DISPATCH-2342 comment header to the cherry-pick [https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;a=commit;h=5d693210b806f5441960a457c68f16fd3fc83606] > Remove use of deprecated proton-c reactor in tests (skupper issue #482) > --- > > Key: DISPATCH-2342 > URL: https://issues.apache.org/jira/browse/DISPATCH-2342 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.19.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.20.0 > > > Backport fix from skupper-router -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2344) Mobile addresses out-of-sync on two routers in a network (skupper-router #473)
[ https://issues.apache.org/jira/browse/DISPATCH-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2344: Assignee: Ken Giusti > Mobile addresses out-of-sync on two routers in a network (skupper-router > #473) > > > Key: DISPATCH-2344 > URL: https://issues.apache.org/jira/browse/DISPATCH-2344 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.19.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.20.0 > > > Backport fix from > [https://github.com/skupperproject/skupper-router/issues/473] > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2344) Mobile addresses out-of-sync on two routers in a network (skupper-router #473)
Ken Giusti created DISPATCH-2344: Summary: Mobile addresses out-of-sync on two routers in a network (skupper-router #473) Key: DISPATCH-2344 URL: https://issues.apache.org/jira/browse/DISPATCH-2344 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.19.0 Reporter: Ken Giusti Fix For: 1.20.0 Backport fix from [https://github.com/skupperproject/skupper-router/issues/473] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2342) Remove use of deprecated proton-c reactor in tests (skupper issue #482)
[ https://issues.apache.org/jira/browse/DISPATCH-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2342: Assignee: Ken Giusti > Remove use of deprecated proton-c reactor in tests (skupper issue #482) > --- > > Key: DISPATCH-2342 > URL: https://issues.apache.org/jira/browse/DISPATCH-2342 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.19.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.20.0 > > > Backport fix from skupper-router -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2342) Remove use of deprecated proton-c reactor in tests (skupper issue #482)
Ken Giusti created DISPATCH-2342: Summary: Remove use of deprecated proton-c reactor in tests (skupper issue #482) Key: DISPATCH-2342 URL: https://issues.apache.org/jira/browse/DISPATCH-2342 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.19.0 Reporter: Ken Giusti Fix For: 1.20.0 Backport fix from skupper-router -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2546) Leak of raw connection pn_event
[
https://issues.apache.org/jira/browse/PROTON-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541003#comment-17541003
]
Ken Giusti edited comment on PROTON-2546 at 5/23/22 3:33 PM:
-
How to reproduce:
Build skupper-router from the main branch in Debug mode
(-DCMAKE_BUILD_TYPE=Debug) with -DRUNTIME_CHECK=asan
Set env vars to filter out known leak suppressions (use the correct path to the
tests/*.supp files, and the lsan.supp is in BUILD directory!) :
export ASAN_OPTIONS="disable_coredump=0 detect_odr_violation=0
strict_string_checks=1 detect_stack_use_after_return=1
check_initialization_order=1 strict_init_order=1 detect_invalid_pointer_pairs=2
suppressions={*}/home/kgiusti/work/skupper/skupper-router/tests/asan.supp{*}"
export LSAN_OPTIONS="disable_coredump=0
suppressions={*}/home/kgiusti/work/skupper/skupper-router/BUILD/tests/lsan.supp{*}"
Run the skupper router against the attached config file:
skrouterd -c proton-2546.conf &
In a separate window, run curl against the router "curl
[http://127.0.0.1:8000|http://127.0.0.1:8000/];
while curl is running, kill the router: $ kill
That should trigger a leak of the pn_raw_connection.
was (Author: kgiusti):
How to reproduce:
Build skupper-router from the main branch in Debug mode
(-DCMAKE_BUILD_TYPE=Debug) with -DRUNTIME_CHECK=asan
Set env vars to filter out known leak suppressions (use the correct path to the
tests/*.supp files, and the lsan.supp is in BUILD directory!) :
export ASAN_OPTIONS="disable_coredump=0 detect_odr_violation=0
strict_string_checks=1 detect_stack_use_after_return=1
check_initialization_order=1 strict_init_order=1 detect_invalid_pointer_pairs=2
suppressions={*}/home/kgiusti/work/skupper/skupper-router/tests/asan.supp{*}"
export LSAN_OPTIONS="disable_coredump=0
suppressions={*}/home/kgiusti/work/skupper/skupper-router/BUILD/tests/lsan.supp{*}"
Run the skupper router against the attached config file:
skrouterd proton-2546.conf &
In a separate window, run curl against the router "curl http://127.0.0.1:8000;
while curl is running, kill the router: $ kill
That should trigger a leak of the pn_raw_connection.
> Leak of raw connection pn_event
> ---
>
> Key: PROTON-2546
> URL: https://issues.apache.org/jira/browse/PROTON-2546
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.38.0
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
> Attachments: proton-2546.conf
>
>
> See:
> [https://github.com/skupperproject/skupper-router/issues/469|https://github.com/skupperproject/skupper-router/issues/469?]
> This leak appeared on main about five days ago:
> https://github.com/skupperproject/skupper-router/runs/6489086985?check_suite_focus=true#step:26:1757
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2546) Leak of raw connection pn_event
[
https://issues.apache.org/jira/browse/PROTON-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541003#comment-17541003
]
Ken Giusti commented on PROTON-2546:
How to reproduce:
Build skupper-router from the main branch in Debug mode
(-DCMAKE_BUILD_TYPE=Debug) with -DRUNTIME_CHECK=asan
Set env vars to filter out known leak suppressions (use the correct path to the
tests/*.supp files, and the lsan.supp is in BUILD directory!) :
export ASAN_OPTIONS="disable_coredump=0 detect_odr_violation=0
strict_string_checks=1 detect_stack_use_after_return=1
check_initialization_order=1 strict_init_order=1 detect_invalid_pointer_pairs=2
suppressions={*}/home/kgiusti/work/skupper/skupper-router/tests/asan.supp{*}"
export LSAN_OPTIONS="disable_coredump=0
suppressions={*}/home/kgiusti/work/skupper/skupper-router/BUILD/tests/lsan.supp{*}"
Run the skupper router against the attached config file:
skrouterd proton-2546.conf &
In a separate window, run curl against the router "curl http://127.0.0.1:8000;
while curl is running, kill the router: $ kill
That should trigger a leak of the pn_raw_connection.
> Leak of raw connection pn_event
> ---
>
> Key: PROTON-2546
> URL: https://issues.apache.org/jira/browse/PROTON-2546
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.38.0
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
> Attachments: proton-2546.conf
>
>
> See:
> [https://github.com/skupperproject/skupper-router/issues/469|https://github.com/skupperproject/skupper-router/issues/469?]
> This leak appeared on main about five days ago:
> https://github.com/skupperproject/skupper-router/runs/6489086985?check_suite_focus=true#step:26:1757
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2546) Leak of raw connection pn_event
[ https://issues.apache.org/jira/browse/PROTON-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-2546: --- Attachment: proton-2546.conf > Leak of raw connection pn_event > --- > > Key: PROTON-2546 > URL: https://issues.apache.org/jira/browse/PROTON-2546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.38.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Major > Attachments: proton-2546.conf > > > See: > [https://github.com/skupperproject/skupper-router/issues/469|https://github.com/skupperproject/skupper-router/issues/469?] > This leak appeared on main about five days ago: > https://github.com/skupperproject/skupper-router/runs/6489086985?check_suite_focus=true#step:26:1757 > > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2546) Leak of raw connection pn_event
[ https://issues.apache.org/jira/browse/PROTON-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17540999#comment-17540999 ] Ken Giusti commented on PROTON-2546: I've been debugging this a bit and think that the pn_raw_connection is being leaked. - Suppressions used: count bytes template *2 3072 ^pn_raw_connection$* 6 384 sys_mutex 390 408014 /libpython3.*.so - SUMMARY: AddressSanitizer: 896 byte(s) leaked in 18 allocation(s). I can reproduce these leaks by shutting down the skupper-router while there is at least one active pn_raw_connection. I shut down the router by sending a SIGTERM to it via kill. In this case the router does not attempt to call pn_raw_connection_close() and wait for the disconnect. Instead the shutdown code calls pn_proactor_free() and expects any outstanding raw connection memory to be freed by that. Is this assumption correct? If no raw connections are present at shutdown these leaks do not occur. > Leak of raw connection pn_event > --- > > Key: PROTON-2546 > URL: https://issues.apache.org/jira/browse/PROTON-2546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.38.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Major > > See: > [https://github.com/skupperproject/skupper-router/issues/469|https://github.com/skupperproject/skupper-router/issues/469?] > This leak appeared on main about five days ago: > https://github.com/skupperproject/skupper-router/runs/6489086985?check_suite_focus=true#step:26:1757 > > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2546) Leak of raw connection pn_event
Ken Giusti created PROTON-2546: -- Summary: Leak of raw connection pn_event Key: PROTON-2546 URL: https://issues.apache.org/jira/browse/PROTON-2546 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.38.0 Reporter: Ken Giusti See: [https://github.com/skupperproject/skupper-router/issues/469|https://github.com/skupperproject/skupper-router/issues/469?] This leak appeared on main about five days ago: https://github.com/skupperproject/skupper-router/runs/6489086985?check_suite_focus=true#step:26:1757 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2546) Leak of raw connection pn_event
[ https://issues.apache.org/jira/browse/PROTON-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-2546: -- Assignee: Andrew Stitcher > Leak of raw connection pn_event > --- > > Key: PROTON-2546 > URL: https://issues.apache.org/jira/browse/PROTON-2546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.38.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Major > > See: > [https://github.com/skupperproject/skupper-router/issues/469|https://github.com/skupperproject/skupper-router/issues/469?] > This leak appeared on main about five days ago: > https://github.com/skupperproject/skupper-router/runs/6489086985?check_suite_focus=true#step:26:1757 > > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2545) raw connection: client disconnect is ignored if no read buffers are available.
[ https://issues.apache.org/jira/browse/PROTON-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-2545: -- Assignee: Andrew Stitcher > raw connection: client disconnect is ignored if no read buffers are available. > -- > > Key: PROTON-2545 > URL: https://issues.apache.org/jira/browse/PROTON-2545 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.37.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Major > > Refer to [https://github.com/skupperproject/skupper-router/issues/477] > TL;DR - if a client closes its TCP connection (full drop - not half close), > the proactor cannot post a PN_RAW_CONNECTION_DISCONNECTED event unless read > buffers have been provided to the raw connection. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2545) raw connection: client disconnect is ignored if no read buffers are available.
Ken Giusti created PROTON-2545: -- Summary: raw connection: client disconnect is ignored if no read buffers are available. Key: PROTON-2545 URL: https://issues.apache.org/jira/browse/PROTON-2545 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.37.0 Reporter: Ken Giusti Refer to [https://github.com/skupperproject/skupper-router/issues/477] TL;DR - if a client closes its TCP connection (full drop - not half close), the proactor cannot post a PN_RAW_CONNECTION_DISCONNECTED event unless read buffers have been provided to the raw connection. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1994) [http2] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http2 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1994. -- Resolution: Won't Fix > [http2] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http2 adaptor > > > Key: DISPATCH-1994 > URL: https://issues.apache.org/jira/browse/DISPATCH-1994 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1993) [http1] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http1 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed DISPATCH-1993. Resolution: Won't Fix > [http1] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http1 adaptor > > > Key: DISPATCH-1993 > URL: https://issues.apache.org/jira/browse/DISPATCH-1993 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors >Reporter: Ganesh Murthy >Assignee: Ken Giusti >Priority: Minor > Labels: HTTP/1.x > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2066) [http1] In system_tests_http1_adaptor Http1AdaptorQ2Standalone backpressure tests, block_ct != unblock_ct
[
https://issues.apache.org/jira/browse/DISPATCH-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti closed DISPATCH-2066.
Resolution: Won't Fix
> [http1] In system_tests_http1_adaptor Http1AdaptorQ2Standalone backpressure
> tests, block_ct != unblock_ct
> -
>
> Key: DISPATCH-2066
> URL: https://issues.apache.org/jira/browse/DISPATCH-2066
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ken Giusti
>Priority: Major
> Labels: HTTP/1.x
> Fix For: 1.20.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/46271#L11501
> {noformat}
> test 70
> Start 70: system_tests_http1_adaptor
> 70: Test command: /usr/bin/python3.8
> "/home/travis/build/apache/qpid-dispatch/build/tests/run.py" "-m" "unittest"
> "-v" "system_tests_http1_adaptor"
> 70: Test timeout computed to be: 500
> 70: test_01_unsolicited_response
> (system_tests_http1_adaptor.Http1AdaptorBadEndpointsTest)
> 70: Create a server that sends an immediate Request Timeout response ... ok
> 70: test_02_bad_request_message
> (system_tests_http1_adaptor.Http1AdaptorBadEndpointsTest)
> 70: Test various improperly constructed request messages ... ok
> 70: test_03_bad_response_message
> (system_tests_http1_adaptor.Http1AdaptorBadEndpointsTest)
> 70: Test various improperly constructed response messages ... ok
> 70:
> 70: Router TestBadEndpoints output file:
> 70:
> 70: -
> 70: Suppressions used:
> 70: count bytes template
> 70: 1 24 ^pn_condition$
> 70: 1 1536 ^pn_raw_connection$
> 70: 1 56 qdr_core_subscribe
> 70: 2112 ^pn_string_grow$
> 70: 7328 ^pn_object_new$
> 70: 1128 ^pn_list$
> 70: 2 48 ^pni_record_create$
> 70: 597 926857 /libpython3.*.so
> 70: -
> 70:
> 70:
> 70:
> 70: test_01_concurrent_requests
> (system_tests_http1_adaptor.Http1AdaptorEdge2EdgeTest)
> 70: Test multiple concurrent clients sending streaming messages ... ok
> 70: test_02_credit_replenish
> (system_tests_http1_adaptor.Http1AdaptorEdge2EdgeTest)
> 70: Verify credit is replenished by sending > the default credit window ... ok
> 70: test_03_server_reconnect
> (system_tests_http1_adaptor.Http1AdaptorEdge2EdgeTest)
> 70: Verify server reconnect logic. ... ok
> 70: test_04_server_pining_for_the_fjords
> (system_tests_http1_adaptor.Http1AdaptorEdge2EdgeTest)
> 70: Test permanent loss of server ... ok
> 70: test_05_large_streaming_msg
> (system_tests_http1_adaptor.Http1AdaptorEdge2EdgeTest)
> 70: Verify large streaming message transfer ... ok
> 70:
> 70: Router EA2 output file:
> 70:
> 70: -
> 70: Suppressions used:
> 70: count bytes template
> 70: 7 59 ^load_server_config$
> 70: 6401 ^qd_dispatch_configure_connector$
> 70: 1 24 ^pn_condition$
> 70: 1 1536 ^pn_raw_connection$
> 70: 1 64 sys_mutex
> 70: 1 56 qdr_core_subscribe
> 70: 2112 ^pn_string_grow$
> 70: 7328 ^pn_object_new$
> 70: 1128 ^pn_list$
> 70: 2 48 ^pni_record_create$
> 70: 601 929697 /libpython3.*.so
> 70: -
> 70:
> 70:
> 70:
> 70:
> 70: Router EA2 debug dump file:
> 70:
> 70: alloc.c: Items of type 'qd_timer_t' remain allocated at shutdown: 1
> (SUPPRESSED)
> 70: alloc.c: Items of type 'qd_connector_t' remain allocated at shutdown: 1
> (SUPPRESSED)
> 70:
> 70:
> 70:
> 70: Router EA1 output file:
> 70:
> 70: -
> 70: Suppressions used:
> 70: count bytes template
> 70: 7 59 ^load_server_config$
> 70: 6401 ^qd_dispatch_configure_connector$
> 70: 1 64 sys_mutex
> 70: 1 56 qdr_core_subscribe
> 70: 601 929697 /libpython3.*.so
> 70: -
> 70:
> 70:
> 70:
> 70:
> 70: Router EA1 debug dump file:
> 70:
> 70: alloc.c: Items of type 'qd_timer_t' remain allocated at shutdown: 1
> (SUPPRESSED)
> 70: alloc.c: Items of type 'qd_connector_t' remain allocated at shutdown: 1
> (SUPPRESSED)
> 70:
> 70:
> 70:
> 70: Router INT.A output file:
> 70:
> 70: -
> 70: Suppressions used:
> 70: count bytes template
> 70: 6336 qdr_core_subscribe
> 70: 633 956953
[jira] [Closed] (DISPATCH-1890) need tests for http1 multicast
[ https://issues.apache.org/jira/browse/DISPATCH-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed DISPATCH-1890. Resolution: Won't Fix > need tests for http1 multicast > -- > > Key: DISPATCH-1890 > URL: https://issues.apache.org/jira/browse/DISPATCH-1890 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Major > Labels: HTTP/1.x > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1892) http1 json aggregation does not handle large messages
[ https://issues.apache.org/jira/browse/DISPATCH-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed DISPATCH-1892. Resolution: Won't Fix > http1 json aggregation does not handle large messages > - > > Key: DISPATCH-1892 > URL: https://issues.apache.org/jira/browse/DISPATCH-1892 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Environment: At some point above 8k the conversion of the message > into a python message is truncating data. >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Major > Labels: HTTP/1.x > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1967) TCP adaptor connections not counted against policy global count
[ https://issues.apache.org/jira/browse/DISPATCH-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed DISPATCH-1967. Resolution: Won't Fix > TCP adaptor connections not counted against policy global count > --- > > Key: DISPATCH-1967 > URL: https://issues.apache.org/jira/browse/DISPATCH-1967 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine, Protocol Adaptors >Affects Versions: 1.15.0 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Major > Fix For: 1.20.0 > > > After many thousand TCP connections the router Policy Status shows > _Connections Processed = 1_. That connection is the management connection > that read the count. > Adaptor connections must be counted by policy and subjected to global count > limits. > This same problem probably exists in the other protocol adaptors. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2093) [tcp] TCP deliveries are counted as modified
[
https://issues.apache.org/jira/browse/DISPATCH-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti closed DISPATCH-2093.
Resolution: Won't Fix
> [tcp] TCP deliveries are counted as modified
>
>
> Key: DISPATCH-2093
> URL: https://issues.apache.org/jira/browse/DISPATCH-2093
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.20.0
>
>
> TCP deliveries that pass over inter router links are being counted as
> 'modified' once the TCP connections complete. Since the inter router links
> survive much longer than the TCP links, the "modified" counters are visible
> long after TCP i done.
>
> Proposed fix:
> Add to void handle_disconnected(qdr_tcp_connection_t* conn):
> {{qd_log(tcp_adaptor->log_source, QD_LOG_DEBUG, "[C%"PRIu64"][L%"PRIu64"]
> handle_disconnected - close outstream", conn->conn_id, conn->outgoing_id);}}
> {{+ qdr_delivery_remote_state_updated(tcp_adaptor->core,}}
> {{+ conn->outstream,}}
> {{+ PN_ACCEPTED,}}
> {{+ true, // settled,}}
> {{+ 0, // delivery state}}
> {{+ false);}}
> {{qdr_delivery_decref(tcp_adaptor->core, conn->outstream,
> "tcp-adaptor.handle_disconnected - outstream");}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2288) Network-centric logging facility for protocol adaptors
[ https://issues.apache.org/jira/browse/DISPATCH-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed DISPATCH-2288. Resolution: Won't Fix > Network-centric logging facility for protocol adaptors > -- > > Key: DISPATCH-2288 > URL: https://issues.apache.org/jira/browse/DISPATCH-2288 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Protocol Adaptors >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.20.0 > > > A separate logging/tracing facility is needed for the protocol adaptors to > serve users that are more accustomed to network/firewall/router logs and are > not concerned with AMQP/messaging/link-protocol details. > This feature will make the use of the protocol adaptors more observable and > debuggable to network-familiar developers and operators. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2087) TCP adaptor listener connections hang if no connectors are defined
[ https://issues.apache.org/jira/browse/DISPATCH-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed DISPATCH-2087. Resolution: Won't Fix > TCP adaptor listener connections hang if no connectors are defined > -- > > Key: DISPATCH-2087 > URL: https://issues.apache.org/jira/browse/DISPATCH-2087 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Charles E. Rolke >Assignee: Ken Giusti >Priority: Major > Fix For: 1.20.0 > > > The proposed 1.16.0 freeze version of the TCP adaptor may have two start up > problems: > * a connector is defined but the server is absent > * no connector is defined > If a connector is defined but the server is absent: > * A client connects to the listener. Listener starts with SYN, SYN/ACK, ACK. > * The client sends the first payload bytes; listener ACKs > * The server connection fails with SYN, RST/ACK, ACK. > * The client connection is closed with FIN, FIN/ACK, ACK > If a connector is not defined: > * A client connects to the listener. Listener starts with SYN, SYN/ACK, ACK. > * The client sends the first payload bytes > * No further traffic is passed on the client connection > * Even if the server is started while the client is waiting no further > traffic is passed on the to the client. > Leaving the client connected forever with no hope of ever passing data is a > bug. Two approaches that would improve service for the client: > * If there is no connector then close the client connection immediately > * If the client connection is left open then when a tcpConnector is defined > attach that connector's server to the in-progress listener connection. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2234) Update JavaScript console packages for the 1.19.0 release
[ https://issues.apache.org/jira/browse/DISPATCH-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2234: - Fix Version/s: 1.19.0 (was: 1.20.0) > Update JavaScript console packages for the 1.19.0 release > - > > Key: DISPATCH-2234 > URL: https://issues.apache.org/jira/browse/DISPATCH-2234 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Reporter: Jiri Daněk >Assignee: Jiri Daněk >Priority: Major > Fix For: 1.19.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2335) Avoid use of tox to run the python linters
[ https://issues.apache.org/jira/browse/DISPATCH-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2335: Assignee: Ganesh Murthy > Avoid use of tox to run the python linters > -- > > Key: DISPATCH-2335 > URL: https://issues.apache.org/jira/browse/DISPATCH-2335 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy >Priority: Major > > Currently the CI uses python tox to run the python linters across all > versions of python installed on the current system. > This is overkill: the linters don't need to be re-run in virtual envs > multiple times - if there are syntax/linter bugs they'll show up with only > one run of the test. > Let's remove the use of tox here and simply invoke the linters directly from > Ctest. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2335) Avoid use of tox to run the python linters
Ken Giusti created DISPATCH-2335: Summary: Avoid use of tox to run the python linters Key: DISPATCH-2335 URL: https://issues.apache.org/jira/browse/DISPATCH-2335 Project: Qpid Dispatch Issue Type: Improvement Components: Tests Affects Versions: 1.18.0 Reporter: Ken Giusti Currently the CI uses python tox to run the python linters across all versions of python installed on the current system. This is overkill: the linters don't need to be re-run in virtual envs multiple times - if there are syntax/linter bugs they'll show up with only one run of the test. Let's remove the use of tox here and simply invoke the linters directly from Ctest. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2333) Fix assert that is always true (detected by Coverity Scan)
[ https://issues.apache.org/jira/browse/DISPATCH-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2333. -- Assignee: Ken Giusti Resolution: Fixed > Fix assert that is always true (detected by Coverity Scan) > -- > > Key: DISPATCH-2333 > URL: https://issues.apache.org/jira/browse/DISPATCH-2333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Trivial > Fix For: 1.19.0 > > > In policy.c: > 292uint64_t nc = n_connections; > 293assert (n_connections >= 0); > > n_connections >= 0 is always true regardless of the values of its operands. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2333) Fix assert that is always true (detected by Coverity Scan)
Ken Giusti created DISPATCH-2333: Summary: Fix assert that is always true (detected by Coverity Scan) Key: DISPATCH-2333 URL: https://issues.apache.org/jira/browse/DISPATCH-2333 Project: Qpid Dispatch Issue Type: Bug Components: Policy Engine Affects Versions: 1.18.0 Reporter: Ken Giusti Fix For: 1.19.0 In policy.c: 292uint64_t nc = n_connections; 293assert (n_connections >= 0); n_connections >= 0 is always true regardless of the values of its operands. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1403) Consolidate chained qd_buffer_t field handling code
[ https://issues.apache.org/jira/browse/DISPATCH-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1403. -- Fix Version/s: 1.19.0 (was: Backlog) Resolution: Fixed > Consolidate chained qd_buffer_t field handling code > --- > > Key: DISPATCH-1403 > URL: https://issues.apache.org/jira/browse/DISPATCH-1403 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Labels: refactor > Fix For: 1.19.0 > > > There are many places in the router's C codebase where we need to work with > data spanning a chained qd_buffer_t list. In particular the low level > operations such as: > * advance N bytes > * compare N bytes > * copy N bytes > are common throughout the code. > Here are examples from the iterator.c library: > [copy > bytes|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L378] > [advance > cursor|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L424] > [compare|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L467] > Similar logic is implemented in message.c and parse.c. > We should de-duplicate this code by providing a common implementation as part > of the buffer handling code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1487) Improve the parsing of message annotations
[ https://issues.apache.org/jira/browse/DISPATCH-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1487. -- Resolution: Fixed > Improve the parsing of message annotations > -- > > Key: DISPATCH-1487 > URL: https://issues.apache.org/jira/browse/DISPATCH-1487 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > ToDo: Refactor inbound MA parsing on inbound inter-router links to improve > throughput and reduce latency. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2276) The latest release of proton (pre-0.37.0) breaks scraper
[ https://issues.apache.org/jira/browse/DISPATCH-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494172#comment-17494172 ] Ken Giusti commented on DISPATCH-2276: -- The return of the Chug!! Hey Chuck - how's things? Side note: the Proton folks seemed interested in taking scraper into their project. It's a good tool to apply to any Proton-based app, not just the router. IIUC they were just missing a body to help support it. The added bonus would be making sure scraper doesn't break whenever they change the proton logs. > The latest release of proton (pre-0.37.0) breaks scraper > > > Key: DISPATCH-2276 > URL: https://issues.apache.org/jira/browse/DISPATCH-2276 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ken Giusti >Assignee: Charles E. Rolke >Priority: Major > > The next version of proton changes the format of the message tracing log > messages. > Scraper needs to be updated to work with these new log formats. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2208) Dispatch docs build fails if -DRUNTIME_CHECK=asan is used
[
https://issues.apache.org/jira/browse/DISPATCH-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti closed DISPATCH-2208.
Resolution: Duplicate
> Dispatch docs build fails if -DRUNTIME_CHECK=asan is used
> -
>
> Key: DISPATCH-2208
> URL: https://issues.apache.org/jira/browse/DISPATCH-2208
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.19.0
>
>
> https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:108
> {noformat}
> [ 87%] Generating qdrouterd_help.adoc
> [109|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:109]==7773==ASan
> runtime does not come first in initial library list; you should either link
> runtime to your application or manually preload it with LD_PRELOAD.
> [110|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:110]Traceback
> (most recent call last):
> [111|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:111]
> File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/run.py",
> line 144, in
> [112|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:112]
> run_path(sys.argv[0], run_name="__main__")
> [113|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:113]
> File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/run.py",
> line 127, in run_path
> [114|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:114]
> runpy.run_path(file_path, run_name=run_name)
> [115|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:115]
> File "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/runpy.py", line
> 263, in run_path
> [116|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:116]
> pkg_name=pkg_name, script_name=fname)
> [117|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:117]
> File "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/runpy.py", line
> 96, in _run_module_code
> [118|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:118]
> mod_name, mod_spec, pkg_name, script_name)
> [119|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:119]
> File "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/runpy.py", line
> 85, in _run_code
> [120|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:120]
> exec(code, run_globals)
> [121|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:121]
> File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/docs/man/help2txt.py",
> line 96, in
> [122|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:122]
> main(sys.argv)
> [123|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:123]
> File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/docs/man/help2txt.py",
> line 92, in main
> [124|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:124]
> print(help2txt(check_output(program)))
> [125|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:125]
> File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/docs/man/help2txt.py",
> line 54, in check_output
> [126|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:126]
> raise e
> [127|https://github.com/jiridanek/qpid-dispatch/runs/2050819641?check_suite_focus=true#step:8:127]subprocess.CalledProcessError:
> Command
> '['/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/router/qdrouterd',
> '--help']' returned non-zero exit status 1.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2297) OneRouter Q2 test failing in system_tests_http2 on rhel 9
[
https://issues.apache.org/jira/browse/DISPATCH-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti closed DISPATCH-2297.
Resolution: Won't Fix
> OneRouter Q2 test failing in system_tests_http2 on rhel 9
> -
>
> Key: DISPATCH-2297
> URL: https://issues.apache.org/jira/browse/DISPATCH-2297
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Tests
>Affects Versions: 1.18.0
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
>
> {noformat}
> 71: Test command: /usr/bin/python3.9
> "/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/build/tests/run.py"
> "-m" "unittest" "-v" "system_tests_http2"
> 71: Test timeout computed to be: 600
> 71: test_q2_block_unblock (system_tests_http2.Http2Q2OneRouterTest) ... ERROR
> 71:
> 71: Router QDR output file:
> 71:
> 71:
> 71:
> 71:
> 71: Router QDR command file:
> 71:
> 71: qdrouterd -c http2-test-router.conf -I
> /home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/python
> 71: pid=7610
> 71:
> 71:
> 71:
> 71: Router QDR log file tail:
> 71:
> 71: 2021-12-08 20:08:23.643322 + ROUTER_CORE (debug) [C3][L2][D1]
> Delivery decref_CT: rc:1 qdr_delivery_unlink_peers_CT - unlinked from peer
> (delivery)
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:640)
> 71: 2021-12-08 20:08:23.643338 + ROUTER_CORE (debug) [C1][L4][D2]
> Delivery decref_CT: rc:2 qdr_delivery_unlink_peers_CT - unlinked from
> delivery (peer)
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:640)
> 71: 2021-12-08 20:08:23.643361 + ROUTER_CORE (debug) [C3][L2][D1]
> Delivery outcome : is unknown (0x0)
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:392)
> 71: 2021-12-08 20:08:23.643373 + ROUTER_CORE (debug) [C3][L2][D1]
> Delivery decref_CT: rc:0 qdr_link_cleanup_deliveries_CT - remove from
> unsettled list
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:640)
> 71: 2021-12-08 20:08:23.643472 + ROUTER_CORE (trace) Core action
> 'link_detach'
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/router_core_thread.c:235)
> 71: 2021-12-08 20:08:23.643493 + ROUTER_CORE (trace) Core action
> 'connection_closed'
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/router_core_thread.c:235)
> 71: 2021-12-08 20:08:23.643514 + ROUTER_CORE (info) [C3][L2] Link closed
> due to connection loss: del=1 presett=0 psdrop=0 acc=0 rej=0 rel=0 mod=0
> delay1=0 delay10=1 blocked=no
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/connections.c:1109)
> 71: 2021-12-08 20:08:23.643546 + ROUTER_CORE (info) [C3][L3] Link closed
> due to connection loss: del=0 presett=0 psdrop=0 acc=0 rej=0 rel=0 mod=0
> delay1=0 delay10=0 blocked=no
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/connections.c:1109)
> 71: 2021-12-08 20:08:23.643559 + ROUTER_CORE (info) [C3] Connection
> Closed
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/connections.c:1604)
> 71: 2021-12-08 20:08:23.643613 + ROUTER_CORE (trace) Core action
> 'delete_http2_connection'
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/router_core_thread.c:235)
> 71: 2021-12-08 20:08:23.643631 + HTTP_ADAPTOR (trace) [C3] Freeing http2
> connection in free_qdr_http2_connection
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:459)
> 71: 2021-12-08 20:08:23.643654 + HTTP_ADAPTOR (trace) [C1] Activation
> triggered, calling pn_raw_connection_wake()
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:1704)
> 71: 2021-12-08 20:08:23.643765 + HTTP_ADAPTOR (trace) [C1]
> PN_RAW_CONNECTION_WAKE Wake-up
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:2539)
> 71: 2021-12-08 20:08:23.643791 + ROUTER_CORE (debug) [C1][L4][D2]
> Delivery incref:rc:3 qdr_link_process_deliveries - holding the
> undelivered delivery locally
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:115)
> 71: 2021-12-08 20:08:23.643825 + HTTP_ADAPTOR (debug) [C1][S1]
> qdr_http_deliver - call handle_outgoing_http
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:2076)
> 71: 2021-12-08 20:08:23.643838 + PROTOCOL
[jira] [Assigned] (DISPATCH-2297) OneRouter Q2 test failing in system_tests_http2 on rhel 9
[
https://issues.apache.org/jira/browse/DISPATCH-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned DISPATCH-2297:
Assignee: Ken Giusti
> OneRouter Q2 test failing in system_tests_http2 on rhel 9
> -
>
> Key: DISPATCH-2297
> URL: https://issues.apache.org/jira/browse/DISPATCH-2297
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Tests
>Affects Versions: 1.18.0
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
>
> {noformat}
> 71: Test command: /usr/bin/python3.9
> "/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/build/tests/run.py"
> "-m" "unittest" "-v" "system_tests_http2"
> 71: Test timeout computed to be: 600
> 71: test_q2_block_unblock (system_tests_http2.Http2Q2OneRouterTest) ... ERROR
> 71:
> 71: Router QDR output file:
> 71:
> 71:
> 71:
> 71:
> 71: Router QDR command file:
> 71:
> 71: qdrouterd -c http2-test-router.conf -I
> /home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/python
> 71: pid=7610
> 71:
> 71:
> 71:
> 71: Router QDR log file tail:
> 71:
> 71: 2021-12-08 20:08:23.643322 + ROUTER_CORE (debug) [C3][L2][D1]
> Delivery decref_CT: rc:1 qdr_delivery_unlink_peers_CT - unlinked from peer
> (delivery)
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:640)
> 71: 2021-12-08 20:08:23.643338 + ROUTER_CORE (debug) [C1][L4][D2]
> Delivery decref_CT: rc:2 qdr_delivery_unlink_peers_CT - unlinked from
> delivery (peer)
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:640)
> 71: 2021-12-08 20:08:23.643361 + ROUTER_CORE (debug) [C3][L2][D1]
> Delivery outcome : is unknown (0x0)
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:392)
> 71: 2021-12-08 20:08:23.643373 + ROUTER_CORE (debug) [C3][L2][D1]
> Delivery decref_CT: rc:0 qdr_link_cleanup_deliveries_CT - remove from
> unsettled list
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:640)
> 71: 2021-12-08 20:08:23.643472 + ROUTER_CORE (trace) Core action
> 'link_detach'
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/router_core_thread.c:235)
> 71: 2021-12-08 20:08:23.643493 + ROUTER_CORE (trace) Core action
> 'connection_closed'
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/router_core_thread.c:235)
> 71: 2021-12-08 20:08:23.643514 + ROUTER_CORE (info) [C3][L2] Link closed
> due to connection loss: del=1 presett=0 psdrop=0 acc=0 rej=0 rel=0 mod=0
> delay1=0 delay10=1 blocked=no
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/connections.c:1109)
> 71: 2021-12-08 20:08:23.643546 + ROUTER_CORE (info) [C3][L3] Link closed
> due to connection loss: del=0 presett=0 psdrop=0 acc=0 rej=0 rel=0 mod=0
> delay1=0 delay10=0 blocked=no
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/connections.c:1109)
> 71: 2021-12-08 20:08:23.643559 + ROUTER_CORE (info) [C3] Connection
> Closed
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/connections.c:1604)
> 71: 2021-12-08 20:08:23.643613 + ROUTER_CORE (trace) Core action
> 'delete_http2_connection'
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/router_core_thread.c:235)
> 71: 2021-12-08 20:08:23.643631 + HTTP_ADAPTOR (trace) [C3] Freeing http2
> connection in free_qdr_http2_connection
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:459)
> 71: 2021-12-08 20:08:23.643654 + HTTP_ADAPTOR (trace) [C1] Activation
> triggered, calling pn_raw_connection_wake()
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:1704)
> 71: 2021-12-08 20:08:23.643765 + HTTP_ADAPTOR (trace) [C1]
> PN_RAW_CONNECTION_WAKE Wake-up
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:2539)
> 71: 2021-12-08 20:08:23.643791 + ROUTER_CORE (debug) [C1][L4][D2]
> Delivery incref:rc:3 qdr_link_process_deliveries - holding the
> undelivered delivery locally
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/router_core/delivery.c:115)
> 71: 2021-12-08 20:08:23.643825 + HTTP_ADAPTOR (debug) [C1][S1]
> qdr_http_deliver - call handle_outgoing_http
> (/home/jenkins/workspace/dispatch/dispatch-rhel9-main/source/dispatch/src/adaptors/http2/http2_adaptor.c:2076)
> 71: 2021-12-08 20:08:23.643838 +
[jira] [Resolved] (DISPATCH-2312) Remove test system_tests_one_router.py::test_07_unsettled_undeliverable
[ https://issues.apache.org/jira/browse/DISPATCH-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2312. -- Assignee: Ken Giusti Resolution: Fixed > Remove test system_tests_one_router.py::test_07_unsettled_undeliverable > --- > > Key: DISPATCH-2312 > URL: https://issues.apache.org/jira/browse/DISPATCH-2312 > Project: Qpid Dispatch > Issue Type: Task >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > This test appears to do nothing except for pausing for QD_TESTTIMEOUT. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2327) system_tests_multi_tenancy flaky link route test failures
[ https://issues.apache.org/jira/browse/DISPATCH-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2327. -- Resolution: Fixed > system_tests_multi_tenancy flaky link route test failures > - > > Key: DISPATCH-2327 > URL: https://issues.apache.org/jira/browse/DISPATCH-2327 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Very occasionally one of the linkRoute tests in the > system_tests_multi_tenancy.py ctests will fail: > 38: FAIL: test_22_two_router_link_route_targeted_no_tenant > (system_tests_multi_tenancy.RouterTest) > > 38: -- > > 38: Traceback (most recent call last): > > 38: File "/home/kgiusti/work/dispatch/qpid-dispatch/test > /system_tests_multi_tenancy.py", line 290, in > test_22_two_router_link_route_targeted_no_tenant > > 38: self.assertIsNone(test.error) > > 38: AssertionError: 'Timeout Expired: n_sent=0 n_rcvd=0 n_settled=0' is not > None > Examining the router logs it appears as if the attempt to use the link route > is rejected with a "no route" error. > I believe the problem is that each test uses the same link route configured > address. Each test starts by establishing the route container connection > then polls the routers waiting for the link route address to propagate. Once > the poll succeeds the test starts. > IIUC what is happening is that at the end of each test the link route address > may still exist in the route tables - it has not been totally removed. This > causes the next test's poll to immediately succeed before the test's link > route has been properly propagated. This results in the failure if the new > link route doesn't establish itself before traffic is sent. > The fix is to have each test wait for all link route addresses to be removed > from the routing tables before the test ends. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2327) system_tests_multi_tenancy flaky link route test failures
[ https://issues.apache.org/jira/browse/DISPATCH-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2327: Assignee: Ken Giusti > system_tests_multi_tenancy flaky link route test failures > - > > Key: DISPATCH-2327 > URL: https://issues.apache.org/jira/browse/DISPATCH-2327 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Very occasionally one of the linkRoute tests in the > system_tests_multi_tenancy.py ctests will fail: > 38: FAIL: test_22_two_router_link_route_targeted_no_tenant > (system_tests_multi_tenancy.RouterTest) > > 38: -- > > 38: Traceback (most recent call last): > > 38: File "/home/kgiusti/work/dispatch/qpid-dispatch/test > /system_tests_multi_tenancy.py", line 290, in > test_22_two_router_link_route_targeted_no_tenant > > 38: self.assertIsNone(test.error) > > 38: AssertionError: 'Timeout Expired: n_sent=0 n_rcvd=0 n_settled=0' is not > None > Examining the router logs it appears as if the attempt to use the link route > is rejected with a "no route" error. > I believe the problem is that each test uses the same link route configured > address. Each test starts by establishing the route container connection > then polls the routers waiting for the link route address to propagate. Once > the poll succeeds the test starts. > IIUC what is happening is that at the end of each test the link route address > may still exist in the route tables - it has not been totally removed. This > causes the next test's poll to immediately succeed before the test's link > route has been properly propagated. This results in the failure if the new > link route doesn't establish itself before traffic is sent. > The fix is to have each test wait for all link route addresses to be removed > from the routing tables before the test ends. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2327) system_tests_multi_tenancy flaky link route test failures
Ken Giusti created DISPATCH-2327: Summary: system_tests_multi_tenancy flaky link route test failures Key: DISPATCH-2327 URL: https://issues.apache.org/jira/browse/DISPATCH-2327 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.18.0 Reporter: Ken Giusti Fix For: 1.19.0 Very occasionally one of the linkRoute tests in the system_tests_multi_tenancy.py ctests will fail: 38: FAIL: test_22_two_router_link_route_targeted_no_tenant (system_tests_multi_tenancy.RouterTest) 38: -- 38: Traceback (most recent call last): 38: File "/home/kgiusti/work/dispatch/qpid-dispatch/test /system_tests_multi_tenancy.py", line 290, in test_22_two_router_link_route_targeted_no_tenant 38: self.assertIsNone(test.error) 38: AssertionError: 'Timeout Expired: n_sent=0 n_rcvd=0 n_settled=0' is not None Examining the router logs it appears as if the attempt to use the link route is rejected with a "no route" error. I believe the problem is that each test uses the same link route configured address. Each test starts by establishing the route container connection then polls the routers waiting for the link route address to propagate. Once the poll succeeds the test starts. IIUC what is happening is that at the end of each test the link route address may still exist in the route tables - it has not been totally removed. This causes the next test's poll to immediately succeed before the test's link route has been properly propagated. This results in the failure if the new link route doesn't establish itself before traffic is sent. The fix is to have each test wait for all link route addresses to be removed from the routing tables before the test ends. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2310. -- Resolution: Fixed Set max length to 127 - ensures str8-utf8 can hold a node id even after we've translated it to include a domain. > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2132) core->uptime_ticks races
[ https://issues.apache.org/jira/browse/DISPATCH-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2132. -- Resolution: Fixed > core->uptime_ticks races > > > Key: DISPATCH-2132 > URL: https://issues.apache.org/jira/browse/DISPATCH-2132 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.16.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Labels: race-condition, tsan > Fix For: 1.19.0 > > > TSAN flags many races while accessing core->uptime_ticks. Likely harmless. > Replace core->uptime_ticks with atomic integer. > > Example: > 30: WARNING: ThreadSanitizer: data race (pid=632294) > 30: Read of size 4 at 0x7b64000352c8 by thread T3: > 30: #0 qdr_link_first_attach > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/connections.c:608 > (libqpid-dispatch.so+0xc5ee8) > 30: #1 AMQP_incoming_link_handler > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_node.c:985 > (libqpid-dispatch.so+0x1247f4) > 30: #2 setup_incoming_link > /home/kgiusti/work/dispatch/qpid-dispatch/src/container.c:205 > (libqpid-dispatch.so+0x7a7f8) > 30: #3 qd_container_handle_event > /home/kgiusti/work/dispatch/qpid-dispatch/src/container.c:670 > (libqpid-dispatch.so+0x7c935) > 30: #4 handle /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1096 > (libqpid-dispatch.so+0x130537) > 30: #5 thread_run /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1121 > (libqpid-dispatch.so+0x13063a) > 30: #6 _thread_init > /home/kgiusti/work/dispatch/qpid-dispatch/src/posix/threading.c:172 > (libqpid-dispatch.so+0xad37a) > 30: #7 (libtsan.so.0+0x2d33f) > 30: > 30: Previous write of size 4 at 0x7b64000352c8 by thread T1: > 30: #0 qdr_process_tick_CT > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/core_timer.c:111 > (libqpid-dispatch.so+0x10a860) > 30: #1 router_core_thread > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/router_core_thread.c:239 > (libqpid-dispatch.so+0xfb2ae) > 30: #2 _thread_init > /home/kgiusti/work/dispatch/qpid-dispatch/src/posix/threading.c:172 > (libqpid-dispatch.so+0xad37a) > 30: #3 (libtsan.so.0+0x2d33f) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2315) TSAN data race in qdr_connection_process
[
https://issues.apache.org/jira/browse/DISPATCH-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned DISPATCH-2315:
Assignee: Ken Giusti
> TSAN data race in qdr_connection_process
>
>
> Key: DISPATCH-2315
> URL: https://issues.apache.org/jira/browse/DISPATCH-2315
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
> Labels: race-condition, tsan
>
> {noformat}
> 62: ERROR
> 62:
> 62: ==
> 62: ERROR: tearDownClass (system_tests_multicast.MulticastLinearTest)
> 62: --
> 62: Traceback (most recent call last):
> 62: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 836, in tearDownClass
> 62: cls.tester.teardown()
> 62: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 779, in teardown
> 62: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 62: RuntimeError: Errors during teardown:
> 62:
> 62: Process 16478 error: exit code 66, expected 0
> 62: qdrouterd -c INT.B.conf -I /home/travis/build/apache/qpid-dispatch/python
> 62:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_multicast/MulticastLinearTest/setUpClass/INT.B-2.cmd
> 62:
> 62: ==
> 62: WARNING: ThreadSanitizer: data race (pid=16478)
> 62: Read of size 1 at 0x7b44000213d4 by thread T2:
> 62: #0 qdr_connection_process
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:405
> (qdrouterd+0x9d9c6)
> 62: #1 AMQP_writable_conn_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:299
> (qdrouterd+0xdbb81)
> 62: #2 writable_handler
> /home/travis/build/apache/qpid-dispatch/src/container.c:388
> (qdrouterd+0x662eb)
> 62: #3 qd_conn_event_batch_complete
> /home/travis/build/apache/qpid-dispatch/src/container.c:478
> (qdrouterd+0x6769b)
> 62: #4 thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1149 (qdrouterd+0xe733e)
> 62: #5 _thread_init
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x8c441)
> 62:
> 62: Previous write of size 1 at 0x7b44000213d4 by thread T1:
> 62: #0 qdr_delivery_mcast_outbound_settled_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:889
> (qdrouterd+0xab913)
> 62: #1 qdr_delivery_mcast_outbound_update_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:1020
> (qdrouterd+0xab913)
> 62: #2 qdr_update_delivery_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:680
> (qdrouterd+0xac615)
> 62: #3 router_core_thread
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core_thread.c:236
> (qdrouterd+0xc0fe0)
> 62: #4 _thread_init
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x8c441)
> 62:
> 62: Location is heap block of size 320 at 0x7b4400021340 allocated by main
> thread:
> 62: #0 posix_memalign
> ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:835
> (libtsan.so.0+0x3046d)
> 62: #1 qd_alloc
> /home/travis/build/apache/qpid-dispatch/src/alloc_pool.c:391
> (qdrouterd+0x54d24)
> 62: #2 new_qdr_delivery_t
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:24
> (qdrouterd+0xa8442)
> 62: #3 qdr_link_deliver_to
> /home/travis/build/apache/qpid-dispatch/src/router_core/transfer.c:99
> (qdrouterd+0xc6ecd)
> 62: #4 AMQP_rx_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:827
> (qdrouterd+0xdf0cf)
> 62: #5 do_receive
> /home/travis/build/apache/qpid-dispatch/src/container.c:219
> (qdrouterd+0x69b54)
> 62: #6 qd_container_handle_event
> /home/travis/build/apache/qpid-dispatch/src/container.c:734
> (qdrouterd+0x69b54)
> 62: #7 handle /home/travis/build/apache/qpid-dispatch/src/server.c:1108
> (qdrouterd+0xe57a9)
> 62: #8 thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1133 (qdrouterd+0xe726c)
> 62: #9 qd_server_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1527 (qdrouterd+0xe7e6f)
> 62: #10 main_process
> /home/travis/build/apache/qpid-dispatch/router/src/main.c:115
> (qdrouterd+0x2dda7)
> 62: #11 main
> /home/travis/build/apache/qpid-dispatch/router/src/main.c:369
> (qdrouterd+0x2d092)
> 62:
> 62: Thread T2 (tid=16481, running) created by main thread at:
> 62: #0 pthread_create
> ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
> (libtsan.so.0+0x5ea79)
> 62: #1 sys_thread
>
[jira] [Commented] (DISPATCH-2315) TSAN data race in qdr_connection_process
[
https://issues.apache.org/jira/browse/DISPATCH-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483400#comment-17483400
]
Ken Giusti commented on DISPATCH-2315:
--
We need to suppress this as well - the settled flag is read/written by
different threads by design.
Not that it's a good design, but to fix this would require a re-think about how
we share state in the router.
> TSAN data race in qdr_connection_process
>
>
> Key: DISPATCH-2315
> URL: https://issues.apache.org/jira/browse/DISPATCH-2315
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Priority: Major
> Labels: race-condition, tsan
>
> {noformat}
> 62: ERROR
> 62:
> 62: ==
> 62: ERROR: tearDownClass (system_tests_multicast.MulticastLinearTest)
> 62: --
> 62: Traceback (most recent call last):
> 62: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 836, in tearDownClass
> 62: cls.tester.teardown()
> 62: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 779, in teardown
> 62: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 62: RuntimeError: Errors during teardown:
> 62:
> 62: Process 16478 error: exit code 66, expected 0
> 62: qdrouterd -c INT.B.conf -I /home/travis/build/apache/qpid-dispatch/python
> 62:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_multicast/MulticastLinearTest/setUpClass/INT.B-2.cmd
> 62:
> 62: ==
> 62: WARNING: ThreadSanitizer: data race (pid=16478)
> 62: Read of size 1 at 0x7b44000213d4 by thread T2:
> 62: #0 qdr_connection_process
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:405
> (qdrouterd+0x9d9c6)
> 62: #1 AMQP_writable_conn_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:299
> (qdrouterd+0xdbb81)
> 62: #2 writable_handler
> /home/travis/build/apache/qpid-dispatch/src/container.c:388
> (qdrouterd+0x662eb)
> 62: #3 qd_conn_event_batch_complete
> /home/travis/build/apache/qpid-dispatch/src/container.c:478
> (qdrouterd+0x6769b)
> 62: #4 thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1149 (qdrouterd+0xe733e)
> 62: #5 _thread_init
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x8c441)
> 62:
> 62: Previous write of size 1 at 0x7b44000213d4 by thread T1:
> 62: #0 qdr_delivery_mcast_outbound_settled_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:889
> (qdrouterd+0xab913)
> 62: #1 qdr_delivery_mcast_outbound_update_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:1020
> (qdrouterd+0xab913)
> 62: #2 qdr_update_delivery_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:680
> (qdrouterd+0xac615)
> 62: #3 router_core_thread
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core_thread.c:236
> (qdrouterd+0xc0fe0)
> 62: #4 _thread_init
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x8c441)
> 62:
> 62: Location is heap block of size 320 at 0x7b4400021340 allocated by main
> thread:
> 62: #0 posix_memalign
> ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:835
> (libtsan.so.0+0x3046d)
> 62: #1 qd_alloc
> /home/travis/build/apache/qpid-dispatch/src/alloc_pool.c:391
> (qdrouterd+0x54d24)
> 62: #2 new_qdr_delivery_t
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:24
> (qdrouterd+0xa8442)
> 62: #3 qdr_link_deliver_to
> /home/travis/build/apache/qpid-dispatch/src/router_core/transfer.c:99
> (qdrouterd+0xc6ecd)
> 62: #4 AMQP_rx_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:827
> (qdrouterd+0xdf0cf)
> 62: #5 do_receive
> /home/travis/build/apache/qpid-dispatch/src/container.c:219
> (qdrouterd+0x69b54)
> 62: #6 qd_container_handle_event
> /home/travis/build/apache/qpid-dispatch/src/container.c:734
> (qdrouterd+0x69b54)
> 62: #7 handle /home/travis/build/apache/qpid-dispatch/src/server.c:1108
> (qdrouterd+0xe57a9)
> 62: #8 thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1133 (qdrouterd+0xe726c)
> 62: #9 qd_server_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1527 (qdrouterd+0xe7e6f)
> 62: #10 main_process
> /home/travis/build/apache/qpid-dispatch/router/src/main.c:115
> (qdrouterd+0x2dda7)
> 62: #11 main
> /home/travis/build/apache/qpid-dispatch/router/src/main.c:369
> (qdrouterd+0x2d092)
> 62:
> 62: Thread T2 (tid=16481, running) created by main thread at:
> 62:
[jira] [Resolved] (DISPATCH-2317) Router per-message annotations version negotiation
[ https://issues.apache.org/jira/browse/DISPATCH-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2317. -- Resolution: Fixed > Router per-message annotations version negotiation > -- > > Key: DISPATCH-2317 > URL: https://issues.apache.org/jira/browse/DISPATCH-2317 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Directly connected routers (and edge routers) exchange per-message router > annotations. In order to support the ability to modify these annotations in > future releases, have a router advertise the format (version) of its message > annotations. > This can be done via a new connection properties value which is set to the > version of annotations accepted by the router. Directly-connected routers > would exchange these versions and agree to use the minimum version advertised. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2318) Double free of subscription on shutdown
[ https://issues.apache.org/jira/browse/DISPATCH-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2318. -- Resolution: Fixed > Double free of subscription on shutdown > --- > > Key: DISPATCH-2318 > URL: https://issues.apache.org/jira/browse/DISPATCH-2318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > qdr_subscribe_CT incorrectly frees the subscription passed in if the action > is being dicarded. > However qdr_subscribe_CT does not own the subscription - a pointer to the > subscription is held by the caller to qdr_core_subscribe(). The caller will > free it. > > 2022-01-26T20:38:30.4511421Z 75: ==3807==ERROR: AddressSanitizer: attempting > double-free on 0x6060b0c0 in thread T3: > > 2022-01-26T20:38:30.5203414Z 75: #0 0x7f1b8b5a3627 in free > (/lib64/libasan.so.6+0xae627) > > 2022-01-26T20:38:30.5211345Z 75: #1 0x879ff3 in qdr_agent_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/agent.c:153 > > 2022-01-26T20:38:30.5229424Z 75: #2 0x92fb3d in qdr_core_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core.c:329 > > 2022-01-26T20:38:30.5243461Z 75: #3 0x99f01d in qd_router_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:2179 > > 2022-01-26T20:38:30.5249436Z 75: #4 0x7fccf2 in qd_dispatch_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/dispatch.c:374 > > 2022-01-26T20:38:30.5752354Z 75: #5 0x5cefb2 in QDR::deinitialize(bool) > const > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/./helpers.hp\ > p:265 > > > 2022-01-26T20:38:30.5753828Z 75: #6 0x5ab4c5 in > check_amqp_listener_startup_log_message(qd_server_config_t, > std::__cxx11::basic_string, std\ > ::allocator >, std::__cxx11::basic_string, > std::allocator >) > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_un\ > ittests/test_listener_startup.cpp:58 > > > 2022-01-26T20:38:30.5755448Z 75: #7 0x5ae797 in operator() > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/test_listener_startup.cpp:129 > > 2022-01-26T20:38:30.5757874Z 75: #8 0x7f1b8ab7f5c3 in > execute_native_thread_routine (/lib64/libstdc++.so.6+0xd95c3) > > 2022-01-26T20:38:30.5758403Z 75: #9 0x7f1b89ec2a86 in start_thread > (/lib64/libc.so.6+0x8da86) > > 2022-01-26T20:38:30.5758836Z 75: #10 0x7f1b89f468d3 in __GI___clone > (/lib64/libc.so.6+0x1118d3) > > 2022-01-26T20:38:30.5759199Z 75: > > > 2022-01-26T20:38:30.5759801Z 75: 0x6060b0c0 is located 0 bytes inside of > 56-byte region [0x6060b0c0,0x6060b0f8) > > 2022-01-26T20:38:30.5760226Z 75: freed by thread T4 here: > > > 2022-01-26T20:38:30.5760605Z 75: #0 0x7f1b8b5a3627 in free > (/lib64/libasan.so.6+0xae627) > > 2022-01-26T20:38:30.5767193Z 75: #1 0x9377b7 in qdr_subscribe_CT > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/route_tables.c:675 > > 2022-01-26T20:38:30.5771793Z 75: #2 0x934a37 in router_core_thread > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core_thread.c:236 > > 2022-01-26T20:38:30.5774021Z 75: #3 0x7f1b89ec2a86 in start_thread > (/lib64/libc.so.6+0x8da86) > > 2022-01-26T20:38:30.5774306Z 75: >
[jira] [Created] (DISPATCH-2320) TSAN: alloc sequence is non-atomic
Ken Giusti created DISPATCH-2320: Summary: TSAN: alloc sequence is non-atomic Key: DISPATCH-2320 URL: https://issues.apache.org/jira/browse/DISPATCH-2320 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.18.0 Reporter: Ken Giusti While the stack below appears to be a double-free of a qd_message_t it is not (see qd_python_send - the message is not shared with a link). The reason TSAN complains is that the sequence number contained in the memory pool item is not atomic. In the trace below the message was freed to the pool then reclaimed for use by qd_python_send. The fact that the sequence # was not synchronized is causing TSAN pain. Fix: make the sequence an atomic counter : WARNING: ThreadSanitizer: data race (pid=1889) : Write of size 8 at 0x7b40af00 by thread T2 (mutexes: write M13): : #0 qd_dealloc /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/alloc_pool.c:470 (qdrouterd+0x44b652) : #1 free_qd_message_t /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/message.c:93 (qdrouterd+0x46e049) : #2 qd_message_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/message.c:1128 (qdrouterd+0x46e049) : #3 qd_python_send /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/python_embedded.c:798 (qdrouterd+0x4830a0) : #4 method_vectorcall_VARARGS (libpython3.10.so.1.0+0x12ca80) : #5 qd_router_timer_handler /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:1622 (qdrouterd+0x4cf2dc) : #6 qd_timer_visit /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/timer.c:320 (qdrouterd+0x4dd7cf) : #7 handle /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1026 (qdrouterd+0x4d8a96) : #8 thread_run /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1141 (qdrouterd+0x4daeb7) : #9 _thread_init /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:172 (qdrouterd+0x4812dd) : : Previous read of size 8 at 0x7b40af00 by main thread: : #0 qd_alloc_sequence /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/alloc_pool.c:514 (qdrouterd+0x44bef0) : #1 qd_alloc_deref_safe_ptr /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/include/qpid/dispatch/alloc_pool.h:102 (qdrouterd+0x45c033) : #2 cleanup_link /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:350 (qdrouterd+0x45c033) : #3 qd_link_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:997 (qdrouterd+0x45c1c9) : #4 qd_link_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:988 (qdrouterd+0x45dd32) : #5 AMQP_link_detach_handler /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:1158 (qdrouterd+0x4d38f1) : #6 AMQP_link_detach_handler /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:1107 (qdrouterd+0x4d38f1) : #7 close_links /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:328 (qdrouterd+0x45c2b9) : #8 qd_container_handle_event /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:525 (qdrouterd+0x45f003) : #9 handle
[jira] [Updated] (DISPATCH-2318) Double free of subscription on shutdown
[ https://issues.apache.org/jira/browse/DISPATCH-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2318: - Summary: Double free of subscription on shutdown (was: Double free of subscription on shudown) > Double free of subscription on shutdown > --- > > Key: DISPATCH-2318 > URL: https://issues.apache.org/jira/browse/DISPATCH-2318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > qdr_subscribe_CT incorrectly frees the subscription passed in if the action > is being dicarded. > However qdr_subscribe_CT does not own the subscription - a pointer to the > subscription is held by the caller to qdr_core_subscribe(). The caller will > free it. > > 2022-01-26T20:38:30.4511421Z 75: ==3807==ERROR: AddressSanitizer: attempting > double-free on 0x6060b0c0 in thread T3: > > 2022-01-26T20:38:30.5203414Z 75: #0 0x7f1b8b5a3627 in free > (/lib64/libasan.so.6+0xae627) > > 2022-01-26T20:38:30.5211345Z 75: #1 0x879ff3 in qdr_agent_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/agent.c:153 > > 2022-01-26T20:38:30.5229424Z 75: #2 0x92fb3d in qdr_core_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core.c:329 > > 2022-01-26T20:38:30.5243461Z 75: #3 0x99f01d in qd_router_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:2179 > > 2022-01-26T20:38:30.5249436Z 75: #4 0x7fccf2 in qd_dispatch_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/dispatch.c:374 > > 2022-01-26T20:38:30.5752354Z 75: #5 0x5cefb2 in QDR::deinitialize(bool) > const > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/./helpers.hp\ > p:265 > > > 2022-01-26T20:38:30.5753828Z 75: #6 0x5ab4c5 in > check_amqp_listener_startup_log_message(qd_server_config_t, > std::__cxx11::basic_string, std\ > ::allocator >, std::__cxx11::basic_string, > std::allocator >) > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_un\ > ittests/test_listener_startup.cpp:58 > > > 2022-01-26T20:38:30.5755448Z 75: #7 0x5ae797 in operator() > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/test_listener_startup.cpp:129 > > 2022-01-26T20:38:30.5757874Z 75: #8 0x7f1b8ab7f5c3 in > execute_native_thread_routine (/lib64/libstdc++.so.6+0xd95c3) > > 2022-01-26T20:38:30.5758403Z 75: #9 0x7f1b89ec2a86 in start_thread > (/lib64/libc.so.6+0x8da86) > > 2022-01-26T20:38:30.5758836Z 75: #10 0x7f1b89f468d3 in __GI___clone > (/lib64/libc.so.6+0x1118d3) > > 2022-01-26T20:38:30.5759199Z 75: > > > 2022-01-26T20:38:30.5759801Z 75: 0x6060b0c0 is located 0 bytes inside of > 56-byte region [0x6060b0c0,0x6060b0f8) > > 2022-01-26T20:38:30.5760226Z 75: freed by thread T4 here: > > > 2022-01-26T20:38:30.5760605Z 75: #0 0x7f1b8b5a3627 in free > (/lib64/libasan.so.6+0xae627) > > 2022-01-26T20:38:30.5767193Z 75: #1 0x9377b7 in qdr_subscribe_CT > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/route_tables.c:675 > > 2022-01-26T20:38:30.5771793Z 75: #2 0x934a37 in router_core_thread > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core_thread.c:236 > > 2022-01-26T20:38:30.5774021Z 75: #3 0x7f1b89ec2a86 in start_thread > (/lib64/libc.so.6+0x8da86) > > 2022-01-26T20:38:30.5774306Z
[jira] [Created] (DISPATCH-2318) Double free of subscription on shudown
Ken Giusti created DISPATCH-2318: Summary: Double free of subscription on shudown Key: DISPATCH-2318 URL: https://issues.apache.org/jira/browse/DISPATCH-2318 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.18.0 Reporter: Ken Giusti Fix For: 1.19.0 qdr_subscribe_CT incorrectly frees the subscription passed in if the action is being dicarded. However qdr_subscribe_CT does not own the subscription - a pointer to the subscription is held by the caller to qdr_core_subscribe(). The caller will free it. 2022-01-26T20:38:30.4511421Z 75: ==3807==ERROR: AddressSanitizer: attempting double-free on 0x6060b0c0 in thread T3: 2022-01-26T20:38:30.5203414Z 75: #0 0x7f1b8b5a3627 in free (/lib64/libasan.so.6+0xae627) 2022-01-26T20:38:30.5211345Z 75: #1 0x879ff3 in qdr_agent_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/agent.c:153 2022-01-26T20:38:30.5229424Z 75: #2 0x92fb3d in qdr_core_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core.c:329 2022-01-26T20:38:30.5243461Z 75: #3 0x99f01d in qd_router_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:2179 2022-01-26T20:38:30.5249436Z 75: #4 0x7fccf2 in qd_dispatch_free /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/dispatch.c:374 2022-01-26T20:38:30.5752354Z 75: #5 0x5cefb2 in QDR::deinitialize(bool) const /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/./helpers.hp\ p:265 2022-01-26T20:38:30.5753828Z 75: #6 0x5ab4c5 in check_amqp_listener_startup_log_message(qd_server_config_t, std::__cxx11::basic_string, std\ ::allocator >, std::__cxx11::basic_string, std::allocator >) /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_un\ ittests/test_listener_startup.cpp:58 2022-01-26T20:38:30.5755448Z 75: #7 0x5ae797 in operator() /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/test_listener_startup.cpp:129 2022-01-26T20:38:30.5757874Z 75: #8 0x7f1b8ab7f5c3 in execute_native_thread_routine (/lib64/libstdc++.so.6+0xd95c3) 2022-01-26T20:38:30.5758403Z 75: #9 0x7f1b89ec2a86 in start_thread (/lib64/libc.so.6+0x8da86) 2022-01-26T20:38:30.5758836Z 75: #10 0x7f1b89f468d3 in __GI___clone (/lib64/libc.so.6+0x1118d3) 2022-01-26T20:38:30.5759199Z 75: 2022-01-26T20:38:30.5759801Z 75: 0x6060b0c0 is located 0 bytes inside of 56-byte region [0x6060b0c0,0x6060b0f8) 2022-01-26T20:38:30.5760226Z 75: freed by thread T4 here: 2022-01-26T20:38:30.5760605Z 75: #0 0x7f1b8b5a3627 in free (/lib64/libasan.so.6+0xae627) 2022-01-26T20:38:30.5767193Z 75: #1 0x9377b7 in qdr_subscribe_CT /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/route_tables.c:675 2022-01-26T20:38:30.5771793Z 75: #2 0x934a37 in router_core_thread /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core_thread.c:236 2022-01-26T20:38:30.5774021Z 75: #3 0x7f1b89ec2a86 in start_thread (/lib64/libc.so.6+0x8da86) 2022-01-26T20:38:30.5774306Z 75: 2022-01-26T20:38:30.5774559Z 75: previously allocated by thread T3 here: 2022-01-26T20:38:30.5776278Z 75: #0 0x7f1b8b5a391f in __interceptor_malloc (/lib64/libasan.so.6+0xae91f)
[jira] [Assigned] (DISPATCH-2318) Double free of subscription on shudown
[ https://issues.apache.org/jira/browse/DISPATCH-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2318: Assignee: Ken Giusti > Double free of subscription on shudown > -- > > Key: DISPATCH-2318 > URL: https://issues.apache.org/jira/browse/DISPATCH-2318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > qdr_subscribe_CT incorrectly frees the subscription passed in if the action > is being dicarded. > However qdr_subscribe_CT does not own the subscription - a pointer to the > subscription is held by the caller to qdr_core_subscribe(). The caller will > free it. > > 2022-01-26T20:38:30.4511421Z 75: ==3807==ERROR: AddressSanitizer: attempting > double-free on 0x6060b0c0 in thread T3: > > 2022-01-26T20:38:30.5203414Z 75: #0 0x7f1b8b5a3627 in free > (/lib64/libasan.so.6+0xae627) > > 2022-01-26T20:38:30.5211345Z 75: #1 0x879ff3 in qdr_agent_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/agent.c:153 > > 2022-01-26T20:38:30.5229424Z 75: #2 0x92fb3d in qdr_core_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core.c:329 > > 2022-01-26T20:38:30.5243461Z 75: #3 0x99f01d in qd_router_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:2179 > > 2022-01-26T20:38:30.5249436Z 75: #4 0x7fccf2 in qd_dispatch_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/dispatch.c:374 > > 2022-01-26T20:38:30.5752354Z 75: #5 0x5cefb2 in QDR::deinitialize(bool) > const > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/./helpers.hp\ > p:265 > > > 2022-01-26T20:38:30.5753828Z 75: #6 0x5ab4c5 in > check_amqp_listener_startup_log_message(qd_server_config_t, > std::__cxx11::basic_string, std\ > ::allocator >, std::__cxx11::basic_string, > std::allocator >) > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_un\ > ittests/test_listener_startup.cpp:58 > > > 2022-01-26T20:38:30.5755448Z 75: #7 0x5ae797 in operator() > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/c_unittests/test_listener_startup.cpp:129 > > 2022-01-26T20:38:30.5757874Z 75: #8 0x7f1b8ab7f5c3 in > execute_native_thread_routine (/lib64/libstdc++.so.6+0xd95c3) > > 2022-01-26T20:38:30.5758403Z 75: #9 0x7f1b89ec2a86 in start_thread > (/lib64/libc.so.6+0x8da86) > > 2022-01-26T20:38:30.5758836Z 75: #10 0x7f1b89f468d3 in __GI___clone > (/lib64/libc.so.6+0x1118d3) > > 2022-01-26T20:38:30.5759199Z 75: > > > 2022-01-26T20:38:30.5759801Z 75: 0x6060b0c0 is located 0 bytes inside of > 56-byte region [0x6060b0c0,0x6060b0f8) > > 2022-01-26T20:38:30.5760226Z 75: freed by thread T4 here: > > > 2022-01-26T20:38:30.5760605Z 75: #0 0x7f1b8b5a3627 in free > (/lib64/libasan.so.6+0xae627) > > 2022-01-26T20:38:30.5767193Z 75: #1 0x9377b7 in qdr_subscribe_CT > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/route_tables.c:675 > > 2022-01-26T20:38:30.5771793Z 75: #2 0x934a37 in router_core_thread > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core_thread.c:236 > > 2022-01-26T20:38:30.5774021Z 75: #3 0x7f1b89ec2a86 in start_thread > (/lib64/libc.so.6+0x8da86) > > 2022-01-26T20:38:30.5774306Z 75: >
[jira] [Resolved] (DISPATCH-2308) temporary address generation infinite loop if router id > 200 characters
[ https://issues.apache.org/jira/browse/DISPATCH-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2308. -- Resolution: Fixed > temporary address generation infinite loop if router id > 200 characters > > > Key: DISPATCH-2308 > URL: https://issues.apache.org/jira/browse/DISPATCH-2308 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > For your consideration... a router with and id > 200 characters: > https://github.com/kgiusti/dispatch/blob/main/src/router_core/modules/address_lookup_client/address_lookup_client.c#L194 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2123) qd_entity_refresh_allocator race in alloc_pool.c
[ https://issues.apache.org/jira/browse/DISPATCH-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2123: - Labels: race-condition tsan (was: ) > qd_entity_refresh_allocator race in alloc_pool.c > > > Key: DISPATCH-2123 > URL: https://issues.apache.org/jira/browse/DISPATCH-2123 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.16.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Labels: race-condition, tsan > Fix For: 1.19.0 > > > qd_entity_refresh_allocator walks all the descriptors reading their contents. > This can happen while the descriptors are being written to during normal > pool operations. > > Example: > > 5: WARNING: ThreadSanitizer: data race (pid=566878) > 65: Read of size 8 at 0x7b0c0d10 by main thread (mutexes: write M13, > write M286, write M9): > 65: #0 qd_entity_refresh_allocator > /home/kgiusti/work/dispatch/qpid-dispatch/src/alloc_pool.c:700 > (libqpid-dispatch.so+0x6cdec) > 65: #1 ffi_call_unix64 (libffi.so.6+0x6aef) > 65: #2 qdr_forward_on_message > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/forwarder.c:336 > (libqpid-dispatch.so+0xe4ff5) > 65: #3 qdr_general_handler > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/router_core.c:929 > (libqpid-dispatch.so+0xf83f6) > 65: #4 qd_timer_visit > /home/kgiusti/work/dispatch/qpid-dispatch/src/timer.c:317 > (libqpid-dispatch.so+0x135b52) > 65: #5 handle /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1006 > (libqpid-dispatch.so+0x12fc8d) > 65: #6 thread_run /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1121 > (libqpid-dispatch.so+0x13063a) > 65: #7 qd_server_run > /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1501 > (libqpid-dispatch.so+0x1328de) > 65: #8 main_process > /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:115 > (qdrouterd+0x40271a) > 65: #9 main /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:369 > (qdrouterd+0x403557) > 65: > 65: Previous write of size 8 at 0x7b0c0d10 by thread T1 (mutexes: write > M305): > 65: #0 qd_dealloc > /home/kgiusti/work/dispatch/qpid-dispatch/src/alloc_pool.c:494 > (libqpid-dispatch.so+0x6bacd) > 65: #1 free_qdr_action_t > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/router_core_thread.c:33 > (libqpid-dispatch.so+0xf9a35) > 65: #2 router_core_thread > /home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/router_core_thread.c:240 > (libqpid-dispatch.so+0xfb2ba) > 65: #3 _thread_init > /home/kgiusti/work/dispatch/qpid-dispatch/src/posix/threading.c:172 > (libqpid-dispatch.so+0xad37a) > 65: #4 (libtsan.so.0+0x2d33f) > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2203) Alloc_pool_item_t sequence number should be atomic
[
https://issues.apache.org/jira/browse/DISPATCH-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated DISPATCH-2203:
-
Labels: race-condition (was: )
> Alloc_pool_item_t sequence number should be atomic
> --
>
> Key: DISPATCH-2203
> URL: https://issues.apache.org/jira/browse/DISPATCH-2203
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Router Node
>Affects Versions: 1.16.1
>Reporter: Charles E. Rolke
>Priority: Major
> Labels: race-condition
>
> Alloc pool uses a sequence number for safe pointer dereferencing.
> {code:java}
> Definition
> Line 55: uintmax_t sequence; // uintmax_t ensures proper alignment of
> following data
> In qd_alloc:
> Line 406: item->sequence = 0;
> in qd_dealloc:
> Line 477: item->sequence++;
> In qd_alloc_sequence:
> Line 525: reuturn item->sequence;
> {code}
> It is reasonably certain that multiple threads will be referencing the same
> item at nearly the same time. The code as shown gets flagged by tsan.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2313) TSAN data race in remote_sasl.c
[
https://issues.apache.org/jira/browse/DISPATCH-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated DISPATCH-2313:
-
Labels: race-condition tsan (was: )
> TSAN data race in remote_sasl.c
> ---
>
> Key: DISPATCH-2313
> URL: https://issues.apache.org/jira/browse/DISPATCH-2313
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Priority: Major
> Labels: race-condition, tsan
>
> {noformat}
> 43: E SUMMARY: ThreadSanitizer: data race
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/remote_sasl.c:425
> in remote_sasl_list_mechs
> 43: E ==
> 43: E ==
> 43: E WARNING: ThreadSanitizer: data race (pid=3109)
> 43: E Read of size 1 at 0x7b041900 by main thread:
> 43: E #0 strlen (libtsan.so.0+0x5c2eb)
> 43: E #1 pn_strdup
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/core/util.c:122
> (libqpid-proton-core.so.10+0x3e2c2)
> 43: E #2 pni_post_sasl_frame
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/sasl/sasl.c:495
> (libqpid-proton-core.so.10+0x3e2c2)
> 43: E #3 pn_output_write_sasl
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/sasl/sasl.c:693
> (libqpid-proton-core.so.10+0x3e819)
> 43: E #4 transport_produce
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/core/transport.c:2820
> (libqpid-proton-core.so.10+0x2f7a4)
> 43: E #5 pn_transport_pending
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/core/transport.c:3110
> (libqpid-proton-core.so.10+0x2f7a4)
> 43: E #6 pn_connection_driver_write_buffer
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/core/connection_driver.c:112
> (libqpid-proton-core.so.10+0x24d5d)
> 43: E #7 ensure_wbuf
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:827
> (libqpid-proton-proactor.so.1+0x8ece)
> 43: E #8 write_flush
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1074
> (libqpid-proton-proactor.so.1+0x8ece)
> 43: E #9 pconnection_process
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1243
> (libqpid-proton-proactor.so.1+0xaa8c)
> 43: E #10 process
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:2209
> (libqpid-proton-proactor.so.1+0x106a6)
> 43: E #11 next_event_batch
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:2419
> (libqpid-proton-proactor.so.1+0x106a6)
> 43: E #12 pn_proactor_wait
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:2650
> (libqpid-proton-proactor.so.1+0x145b2)
> 43: E #13 thread_run
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1118
> (qdrouterd+0x4dadb9)
> 43: E #14 qd_server_run
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1527
> (qdrouterd+0x4dba5c)
> 43: E #15 main_process
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/router/src/main.c:115
> (qdrouterd+0x426e5c)
> 43: E #16 main
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/router/src/main.c:369
> (qdrouterd+0x42626c)
> 43: E
> 43: E Previous write of size 8 at 0x7b041900 by thread T2:
> 43: E #0 malloc (libtsan.so.0+0x32919)
> 43: E #1 strdup (libc.so.6+0x9ffbe)
> 43: E #2 qd_strdup
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/include/qpid/dispatch/ctools.h:266
> (qdrouterd+0x480647)
> 43: E #3 remote_sasl_process_mechanisms
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/remote_sasl.c:378
> (qdrouterd+0x480647)
> 43: E #4 pni_sasl_impl_process_mechanisms
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/sasl/sasl.c:239
> (libqpid-proton-core.so.10+0x402eb)
> 43: E #5 pn_do_mechanisms
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/sasl/sasl.c:956
> (libqpid-proton-core.so.10+0x402eb)
> 43: E #6 pni_dispatch_action
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/core/dispatcher.c:75
> (libqpid-proton-core.so.10+0x221f8)
> 43: E #7 pni_dispatch_frame
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/core/dispatcher.c:116
> (libqpid-proton-core.so.10+0x221f8)
> 43: E #8 pn_dispatcher_input
>
[jira] [Updated] (DISPATCH-2314) TSAN data race when setting the presettled flag
[
https://issues.apache.org/jira/browse/DISPATCH-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated DISPATCH-2314:
-
Labels: race-condition tsan (was: )
> TSAN data race when setting the presettled flag
> ---
>
> Key: DISPATCH-2314
> URL: https://issues.apache.org/jira/browse/DISPATCH-2314
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Priority: Major
> Labels: race-condition, tsan
>
> {noformat}
> 21: E Process 2380 error: exit code 66, expected 0
> 21: E qdrouterd -c test-router.conf -I
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python
> 21: E
> /__w/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/system_test.dir/system_tests_one_router/OneRouterTest/setUpClass/test-router-9.cmd
> 21: E
> 21: E ==
> 21: E WARNING: ThreadSanitizer: data race (pid=2380)
> 21: E Write of size 1 at 0x7b440003d355 by thread T4:
> 21: E #0 qdr_delivery_set_presettled
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/delivery.c:136
> (qdrouterd+0x49d8c5)
> 21: E #1 AMQP_rx_handler
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:538
> (qdrouterd+0x4d2ff5)
> 21: E #2 deferred_AMQP_rx_handler
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:922
> (qdrouterd+0x4d37b2)
> 21: E #3 invoke_deferred_calls
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:801
> (qdrouterd+0x4d584b)
> 21: E #4 invoke_deferred_calls
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:790
> (qdrouterd+0x4d8b16)
> 21: E #5 handle
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1058
> (qdrouterd+0x4d8b16)
> 21: E #6 thread_run
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1133
> (qdrouterd+0x4dae84)
> 21: E #7 _thread_init
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x48160d)
> 21: E
> 21: E Previous read of size 1 at 0x7b440003d355 by thread T1:
> 21: E #0 qdr_delivery_continue_CT
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/delivery.c:1108
> (qdrouterd+0x49f9e2)
> 21: E #1 router_core_thread
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core_thread.c:236
> (qdrouterd+0x4b572a)
> 21: E #2 _thread_init
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x48160d)
> 21: E
> 21: E Location is heap block of size 320 at 0x7b440003d2c0
> allocated by thread T3:
> 21: E #0 posix_memalign (libtsan.so.0+0x32a23)
> 21: E #1 qd_alloc
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/alloc_pool.c:391
> (qdrouterd+0x44ad29)
> 21: E #2 new_qdr_delivery_t
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/delivery.c:24
> (qdrouterd+0x49d33c)
> 21: E #3 qdr_link_deliver
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/transfer.c:64
> (qdrouterd+0x4bb125)
> 21: E #4 AMQP_rx_handler
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_node.c:877
> (qdrouterd+0x4d3106)
> 21: E #5 do_receive
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:219
> (qdrouterd+0x45f234)
> 21: E #6 qd_container_handle_event
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/container.c:734
> (qdrouterd+0x45f234)
> 21: E #7 handle
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1108
> (qdrouterd+0x4d8b41)
> 21: E #8 thread_run
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1133
> (qdrouterd+0x4dae84)
> 21: E #9 _thread_init
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x48160d)
> 21: E
> 21: E Thread T4 (tid=2385, running) created by main thread at:
> 21: E #0 pthread_create (libtsan.so.0+0x5bef5)
> 21: E #1 sys_thread
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:181
> (qdrouterd+0x481a9c)
> 21: E #2 qd_server_run
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1525
> (qdrouterd+0x4dba3c)
>
[jira] [Updated] (DISPATCH-2315) TSAN data race in qdr_connection_process
[
https://issues.apache.org/jira/browse/DISPATCH-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated DISPATCH-2315:
-
Labels: race-condition tsan (was: )
> TSAN data race in qdr_connection_process
>
>
> Key: DISPATCH-2315
> URL: https://issues.apache.org/jira/browse/DISPATCH-2315
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Priority: Major
> Labels: race-condition, tsan
>
> {noformat}
> 62: ERROR
> 62:
> 62: ==
> 62: ERROR: tearDownClass (system_tests_multicast.MulticastLinearTest)
> 62: --
> 62: Traceback (most recent call last):
> 62: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 836, in tearDownClass
> 62: cls.tester.teardown()
> 62: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 779, in teardown
> 62: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 62: RuntimeError: Errors during teardown:
> 62:
> 62: Process 16478 error: exit code 66, expected 0
> 62: qdrouterd -c INT.B.conf -I /home/travis/build/apache/qpid-dispatch/python
> 62:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_multicast/MulticastLinearTest/setUpClass/INT.B-2.cmd
> 62:
> 62: ==
> 62: WARNING: ThreadSanitizer: data race (pid=16478)
> 62: Read of size 1 at 0x7b44000213d4 by thread T2:
> 62: #0 qdr_connection_process
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:405
> (qdrouterd+0x9d9c6)
> 62: #1 AMQP_writable_conn_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:299
> (qdrouterd+0xdbb81)
> 62: #2 writable_handler
> /home/travis/build/apache/qpid-dispatch/src/container.c:388
> (qdrouterd+0x662eb)
> 62: #3 qd_conn_event_batch_complete
> /home/travis/build/apache/qpid-dispatch/src/container.c:478
> (qdrouterd+0x6769b)
> 62: #4 thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1149 (qdrouterd+0xe733e)
> 62: #5 _thread_init
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x8c441)
> 62:
> 62: Previous write of size 1 at 0x7b44000213d4 by thread T1:
> 62: #0 qdr_delivery_mcast_outbound_settled_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:889
> (qdrouterd+0xab913)
> 62: #1 qdr_delivery_mcast_outbound_update_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:1020
> (qdrouterd+0xab913)
> 62: #2 qdr_update_delivery_CT
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:680
> (qdrouterd+0xac615)
> 62: #3 router_core_thread
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core_thread.c:236
> (qdrouterd+0xc0fe0)
> 62: #4 _thread_init
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:172
> (qdrouterd+0x8c441)
> 62:
> 62: Location is heap block of size 320 at 0x7b4400021340 allocated by main
> thread:
> 62: #0 posix_memalign
> ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:835
> (libtsan.so.0+0x3046d)
> 62: #1 qd_alloc
> /home/travis/build/apache/qpid-dispatch/src/alloc_pool.c:391
> (qdrouterd+0x54d24)
> 62: #2 new_qdr_delivery_t
> /home/travis/build/apache/qpid-dispatch/src/router_core/delivery.c:24
> (qdrouterd+0xa8442)
> 62: #3 qdr_link_deliver_to
> /home/travis/build/apache/qpid-dispatch/src/router_core/transfer.c:99
> (qdrouterd+0xc6ecd)
> 62: #4 AMQP_rx_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:827
> (qdrouterd+0xdf0cf)
> 62: #5 do_receive
> /home/travis/build/apache/qpid-dispatch/src/container.c:219
> (qdrouterd+0x69b54)
> 62: #6 qd_container_handle_event
> /home/travis/build/apache/qpid-dispatch/src/container.c:734
> (qdrouterd+0x69b54)
> 62: #7 handle /home/travis/build/apache/qpid-dispatch/src/server.c:1108
> (qdrouterd+0xe57a9)
> 62: #8 thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1133 (qdrouterd+0xe726c)
> 62: #9 qd_server_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1527 (qdrouterd+0xe7e6f)
> 62: #10 main_process
> /home/travis/build/apache/qpid-dispatch/router/src/main.c:115
> (qdrouterd+0x2dda7)
> 62: #11 main
> /home/travis/build/apache/qpid-dispatch/router/src/main.c:369
> (qdrouterd+0x2d092)
> 62:
> 62: Thread T2 (tid=16481, running) created by main thread at:
> 62: #0 pthread_create
> ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
> (libtsan.so.0+0x5ea79)
> 62: #1 sys_thread
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:181
>
[jira] [Created] (DISPATCH-2317) Router per-message annotations version negotiation
Ken Giusti created DISPATCH-2317: Summary: Router per-message annotations version negotiation Key: DISPATCH-2317 URL: https://issues.apache.org/jira/browse/DISPATCH-2317 Project: Qpid Dispatch Issue Type: New Feature Components: Router Node Affects Versions: 1.18.0 Reporter: Ken Giusti Fix For: 1.19.0 Directly connected routers (and edge routers) exchange per-message router annotations. In order to support the ability to modify these annotations in future releases, have a router advertise the format (version) of its message annotations. This can be done via a new connection properties value which is set to the version of annotations accepted by the router. Directly-connected routers would exchange these versions and agree to use the minimum version advertised. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2317) Router per-message annotations version negotiation
[ https://issues.apache.org/jira/browse/DISPATCH-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2317: Assignee: Ken Giusti > Router per-message annotations version negotiation > -- > > Key: DISPATCH-2317 > URL: https://issues.apache.org/jira/browse/DISPATCH-2317 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Directly connected routers (and edge routers) exchange per-message router > annotations. In order to support the ability to modify these annotations in > future releases, have a router advertise the format (version) of its message > annotations. > This can be done via a new connection properties value which is set to the > version of annotations accepted by the router. Directly-connected routers > would exchange these versions and agree to use the minimum version advertised. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2309) Message body validation can succeed without validating the actual message body
[ https://issues.apache.org/jira/browse/DISPATCH-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2309. -- Resolution: Fixed > Message body validation can succeed without validating the actual message body > -- > > Key: DISPATCH-2309 > URL: https://issues.apache.org/jira/browse/DISPATCH-2309 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > See > https://github.com/apache/qpid-dispatch/blob/759aa173e440b139a7b6e05314e37b7f39d24d69/src/message.c#L2172 > and also this: > [https://github.com/apache/qpid-dispatch/blob/759aa173e440b139a7b6e05314e37b7f39d24d69/src/message.c#L2206] > The router should not be attempting to validate the body of a streaming > message - it isn't possible to do this with confidence. > The only time the router should be validating the entire body is for messages > that are to be consumed by the router itself (subscriptions, router protocol, > management, etc). > Attempting to validate a streaming BODY via qd_message_check() should be > treated as a programming error and assert(). > Protocol adaptors (which must validate body sections) should use the > qd_message_stream_data api which will validate streaming body sections > properly. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2311) Investigate python library leak reported by ASAN
[ https://issues.apache.org/jira/browse/DISPATCH-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479452#comment-17479452 ] Ken Giusti commented on DISPATCH-2311: -- Bumped down from blocker: apparent in 1.18.0 release so not a regression. > Investigate python library leak reported by ASAN > > > Key: DISPATCH-2311 > URL: https://issues.apache.org/jira/browse/DISPATCH-2311 > Project: Qpid Dispatch > Issue Type: Task > Components: Router Node >Reporter: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > CI tests build with ASAN are consistently reporting that the internal python > code has over 1/2 MB of leaked memory. > Before releasing 1.19.0 we need to rule out the possibility that these leaks > are caused by a leak in the router's python codebase. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2311) Investigate python library leak reported by ASAN
[ https://issues.apache.org/jira/browse/DISPATCH-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2311: - Priority: Major (was: Blocker) > Investigate python library leak reported by ASAN > > > Key: DISPATCH-2311 > URL: https://issues.apache.org/jira/browse/DISPATCH-2311 > Project: Qpid Dispatch > Issue Type: Task > Components: Router Node >Reporter: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > CI tests build with ASAN are consistently reporting that the internal python > code has over 1/2 MB of leaked memory. > Before releasing 1.19.0 we need to rule out the possibility that these leaks > are caused by a leak in the router's python codebase. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2312) Remove test system_tests_one_router.py::test_07_unsettled_undeliverable
Ken Giusti created DISPATCH-2312: Summary: Remove test system_tests_one_router.py::test_07_unsettled_undeliverable Key: DISPATCH-2312 URL: https://issues.apache.org/jira/browse/DISPATCH-2312 Project: Qpid Dispatch Issue Type: Task Reporter: Ken Giusti Fix For: 1.19.0 This test appears to do nothing except for pausing for QD_TESTTIMEOUT. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2311) Investigate python library leak reported by ASAN
[ https://issues.apache.org/jira/browse/DISPATCH-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479446#comment-17479446 ] Ken Giusti commented on DISPATCH-2311: -- Example: running system_tests_one_router with Debug Build and ASAN: 21: 21: Router QDR output file: 21: 21: - 21: Suppressions used: 21: count bytes template 21: 1 56 ^IoAdapter_init$ 21: 60 150 ^qd_policy_open_fetch_settings$ 21: 1 32 ^qd_policy_c_counts_alloc$ 21: 597 595257 /libpython3.*.so 21: - > Investigate python library leak reported by ASAN > > > Key: DISPATCH-2311 > URL: https://issues.apache.org/jira/browse/DISPATCH-2311 > Project: Qpid Dispatch > Issue Type: Task > Components: Router Node >Reporter: Ken Giusti >Priority: Blocker > Fix For: 1.19.0 > > > CI tests build with ASAN are consistently reporting that the internal python > code has over 1/2 MB of leaked memory. > Before releasing 1.19.0 we need to rule out the possibility that these leaks > are caused by a leak in the router's python codebase. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2311) Investigate python library leak reported by ASAN
Ken Giusti created DISPATCH-2311: Summary: Investigate python library leak reported by ASAN Key: DISPATCH-2311 URL: https://issues.apache.org/jira/browse/DISPATCH-2311 Project: Qpid Dispatch Issue Type: Task Components: Router Node Reporter: Ken Giusti Fix For: 1.19.0 CI tests build with ASAN are consistently reporting that the internal python code has over 1/2 MB of leaked memory. Before releasing 1.19.0 we need to rule out the possibility that these leaks are caused by a leak in the router's python codebase. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2293) Review use of qd_parse()
[ https://issues.apache.org/jira/browse/DISPATCH-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2293: - Fix Version/s: 1.19.0 > Review use of qd_parse() > > > Key: DISPATCH-2293 > URL: https://issues.apache.org/jira/browse/DISPATCH-2293 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Review the use of qd_parse() to ensure callers _always_ verify the return > value before using it. > qd_parse() is used to parse amqp messages. Since these messages are coming > from an external entity all callers must check that there were no parse > errors. > > Use qd_parse_ok(return_value) to verify the return value. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2293) Review use of qd_parse()
[ https://issues.apache.org/jira/browse/DISPATCH-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2293: Assignee: Ken Giusti > Review use of qd_parse() > > > Key: DISPATCH-2293 > URL: https://issues.apache.org/jira/browse/DISPATCH-2293 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Review the use of qd_parse() to ensure callers _always_ verify the return > value before using it. > qd_parse() is used to parse amqp messages. Since these messages are coming > from an external entity all callers must check that there were no parse > errors. > > Use qd_parse_ok(return_value) to verify the return value. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2302) Segfault in core_client_api.c on shutdown
[ https://issues.apache.org/jira/browse/DISPATCH-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2302: - Fix Version/s: 1.19.0 > Segfault in core_client_api.c on shutdown > - > > Key: DISPATCH-2302 > URL: https://issues.apache.org/jira/browse/DISPATCH-2302 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > Attachments: NEW_BUG.txt > > > Hard to reproduce - I hit this only due to a buggy patch I was working on but > seems legit: > During shutdown qdr_core_free() cleans up any outstanding endpoint clients. > This results in any outstanding core client RPC calls to be cancelled by > invoking the "free request" logic which invokes the "request done" client > handler with the error parameter set to "link detach". > In the case of the edge router client address lookup module, the error is > ignored and the client assumes the request was successful. At this point it > attempts to process the request which results in a segfault. > We need to audit all the core client "request done" callbacks to make sure > the error flag is being checked and properly handled. > See backtrace in attachment > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2308) temporary address generation infinite loop if router id > 200 characters
[ https://issues.apache.org/jira/browse/DISPATCH-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2308: - Fix Version/s: 1.19.0 > temporary address generation infinite loop if router id > 200 characters > > > Key: DISPATCH-2308 > URL: https://issues.apache.org/jira/browse/DISPATCH-2308 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > For your consideration... a router with and id > 200 characters: > https://github.com/kgiusti/dispatch/blob/main/src/router_core/modules/address_lookup_client/address_lookup_client.c#L194 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2310: - Fix Version/s: 1.19.0 > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2309) Message body validation can succeed without validating the actual message body
[ https://issues.apache.org/jira/browse/DISPATCH-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-2309: - Fix Version/s: 1.19.0 > Message body validation can succeed without validating the actual message body > -- > > Key: DISPATCH-2309 > URL: https://issues.apache.org/jira/browse/DISPATCH-2309 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > See > https://github.com/apache/qpid-dispatch/blob/759aa173e440b139a7b6e05314e37b7f39d24d69/src/message.c#L2172 > and also this: > [https://github.com/apache/qpid-dispatch/blob/759aa173e440b139a7b6e05314e37b7f39d24d69/src/message.c#L2206] > The router should not be attempting to validate the body of a streaming > message - it isn't possible to do this with confidence. > The only time the router should be validating the entire body is for messages > that are to be consumed by the router itself (subscriptions, router protocol, > management, etc). > Attempting to validate a streaming BODY via qd_message_check() should be > treated as a programming error and assert(). > Protocol adaptors (which must validate body sections) should use the > qd_message_stream_data api which will validate streaming body sections > properly. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2302) Segfault in core_client_api.c on shutdown
[ https://issues.apache.org/jira/browse/DISPATCH-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2302: Assignee: Ken Giusti > Segfault in core_client_api.c on shutdown > - > > Key: DISPATCH-2302 > URL: https://issues.apache.org/jira/browse/DISPATCH-2302 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Attachments: NEW_BUG.txt > > > Hard to reproduce - I hit this only due to a buggy patch I was working on but > seems legit: > During shutdown qdr_core_free() cleans up any outstanding endpoint clients. > This results in any outstanding core client RPC calls to be cancelled by > invoking the "free request" logic which invokes the "request done" client > handler with the error parameter set to "link detach". > In the case of the edge router client address lookup module, the error is > ignored and the client assumes the request was successful. At this point it > attempts to process the request which results in a segfault. > We need to audit all the core client "request done" callbacks to make sure > the error flag is being checked and properly handled. > See backtrace in attachment > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2309) Message body validation can succeed without validating the actual message body
[ https://issues.apache.org/jira/browse/DISPATCH-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2309: Assignee: Ken Giusti > Message body validation can succeed without validating the actual message body > -- > > Key: DISPATCH-2309 > URL: https://issues.apache.org/jira/browse/DISPATCH-2309 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > See > https://github.com/apache/qpid-dispatch/blob/759aa173e440b139a7b6e05314e37b7f39d24d69/src/message.c#L2172 > and also this: > [https://github.com/apache/qpid-dispatch/blob/759aa173e440b139a7b6e05314e37b7f39d24d69/src/message.c#L2206] > The router should not be attempting to validate the body of a streaming > message - it isn't possible to do this with confidence. > The only time the router should be validating the entire body is for messages > that are to be consumed by the router itself (subscriptions, router protocol, > management, etc). > Attempting to validate a streaming BODY via qd_message_check() should be > treated as a programming error and assert(). > Protocol adaptors (which must validate body sections) should use the > qd_message_stream_data api which will validate streaming body sections > properly. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2308) temporary address generation infinite loop if router id > 200 characters
[ https://issues.apache.org/jira/browse/DISPATCH-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2308: Assignee: Ken Giusti > temporary address generation infinite loop if router id > 200 characters > > > Key: DISPATCH-2308 > URL: https://issues.apache.org/jira/browse/DISPATCH-2308 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > For your consideration... a router with and id > 200 characters: > https://github.com/kgiusti/dispatch/blob/main/src/router_core/modules/address_lookup_client/address_lookup_client.c#L194 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-2310: Assignee: Ken Giusti > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
