[jira] [Updated] (PROTON-2077) Change Minimum supported Visual Studio compiler to 2015
[
https://issues.apache.org/jira/browse/PROTON-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-2077:
Description:
The primary goal here is so we can change the project C support to C99
everywhere.
So we need to ensure that all the C Windows code is actually C99 or actually
compile it as C++.
Because {{snprintf}} is only supported in Visual Studio 2015. Using
{{snprintf}} is the best fix for the buffer overrun in {{pn_proactor_addr}}, as
per [https://github.com/apache/qpid-proton/pull/176]
Also, printf supports {{%zu}} for printing size_t (since Visual Studio 2013).
Does anyone use anything older than Visual Studio 2015 with Proton, at this
point?
was:
Because {{snprintf}} is only supported in Visual Studio 2015. Using
{{snprintf}} is the best fix for the buffer overrun in {{pn_proactor_addr}}, as
per https://github.com/apache/qpid-proton/pull/176
Also, printf supports {{%zu}} for printing size_t (since Visual Studio 2013).
Does anyone use anything older than Visual Studio 2015 with Proton, at this
point?
> Change Minimum supported Visual Studio compiler to 2015
> ---
>
> Key: PROTON-2077
> URL: https://issues.apache.org/jira/browse/PROTON-2077
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build
>Affects Versions: proton-c-0.27.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>
> The primary goal here is so we can change the project C support to C99
> everywhere.
> So we need to ensure that all the C Windows code is actually C99 or actually
> compile it as C++.
> Because {{snprintf}} is only supported in Visual Studio 2015. Using
> {{snprintf}} is the best fix for the buffer overrun in {{pn_proactor_addr}},
> as per [https://github.com/apache/qpid-proton/pull/176]
> Also, printf supports {{%zu}} for printing size_t (since Visual Studio 2013).
> Does anyone use anything older than Visual Studio 2015 with Proton, at this
> point?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2077) Change Minimum supported Visual Studio compiler to 2015
[
https://issues.apache.org/jira/browse/PROTON-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-2077:
Summary: Change Minimum supported Visual Studio compiler to 2015 (was:
Support Visual Studio 2015 and up)
> Change Minimum supported Visual Studio compiler to 2015
> ---
>
> Key: PROTON-2077
> URL: https://issues.apache.org/jira/browse/PROTON-2077
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build
>Affects Versions: proton-c-0.27.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>
> Because {{snprintf}} is only supported in Visual Studio 2015. Using
> {{snprintf}} is the best fix for the buffer overrun in {{pn_proactor_addr}},
> as per https://github.com/apache/qpid-proton/pull/176
> Also, printf supports {{%zu}} for printing size_t (since Visual Studio 2013).
> Does anyone use anything older than Visual Studio 2015 with Proton, at this
> point?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2077) Support Visual Studio 2015 and up
[
https://issues.apache.org/jira/browse/PROTON-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher reassigned PROTON-2077:
---
Assignee: Andrew Stitcher
> Support Visual Studio 2015 and up
> -
>
> Key: PROTON-2077
> URL: https://issues.apache.org/jira/browse/PROTON-2077
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build
>Affects Versions: proton-c-0.27.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>
> Because {{snprintf}} is only supported in Visual Studio 2015. Using
> {{snprintf}} is the best fix for the buffer overrun in {{pn_proactor_addr}},
> as per https://github.com/apache/qpid-proton/pull/176
> Also, printf supports {{%zu}} for printing size_t (since Visual Studio 2013).
> Does anyone use anything older than Visual Studio 2015 with Proton, at this
> point?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2208) Change base C language/compiler requirements to C99 or equivalent
[ https://issues.apache.org/jira/browse/PROTON-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-2208: --- Assignee: Andrew Stitcher > Change base C language/compiler requirements to C99 or equivalent > - > > Key: PROTON-2208 > URL: https://issues.apache.org/jira/browse/PROTON-2208 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > The current language supposedly supported for clients by proton-c is C89. The > current language allowed for implementing proton-c is the common subset of > C89 and C++03. This was to support Visual Studio which at the time didn't > support enough C99. > This led to significant build complexity so we can build proton-c as C++ on > Visual Studio. > Since Visual Studio 2013/2015, Visual Studio has had sufficient C99 support > to compile proton. > It would allow us to significantly simplify the build process, library usage > and ongoing code maintenance requirements if we only supported VS2015 and > later (or if necessary VS2013 - VS2015 would be better as it has C library > compatibility changes). Stripping the complex build hacks and header file > hacks that support earlier Visual Studio compilers. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2248) [Proton-c] Codec pn_data_vfill() method has symbol and string types interchanged.
[
https://issues.apache.org/jira/browse/PROTON-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154911#comment-17154911
]
Andrew Stitcher commented on PROTON-2248:
-
Given this is internal documentation - I'd rather suspect this is a doc error.
However we need to check all the uses of the 'S and 's' codes just to be sure
they are correct in effect.
> [Proton-c] Codec pn_data_vfill() method has symbol and string types
> interchanged.
> -
>
> Key: PROTON-2248
> URL: https://issues.apache.org/jira/browse/PROTON-2248
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Major
>
> The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string
> types interchanged. The function documentation states:
> {noformat}
> /* Format codes:
>code: AMQP-type (arguments)
>...
>S: symbol (char*)
>s: string (char*)
>...
> */
> {noformat}
> but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
> {noformat}
> if (code == 'S') {
> err = pn_data_put_string(data, pn_bytes(size, start));
> } else {
> err = pn_data_put_symbol(data, pn_bytes(size, start));
> }
> {noformat}
> Guidance is needed on whether to fix the reversal and keep the stated codes,
> or reverse the codes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2244) [Proton-c] Encoder error for array of lists where first list in array is empty
[
https://issues.apache.org/jira/browse/PROTON-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154900#comment-17154900
]
ASF subversion and git services commented on PROTON-2244:
-
Commit 9bcec751c0e5444c5397df0eaf48d0da72a1a0b8 in qpid-proton's branch
refs/heads/array-of-lists-first-list-empty from Kim van der Riet
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=9bcec75 ]
PROTON-2244: Removed debug statements erroneously left in code from previous
commit
> [Proton-c] Encoder error for array of lists where first list in array is empty
> --
>
> Key: PROTON-2244
> URL: https://issues.apache.org/jira/browse/PROTON-2244
> Project: Qpid Proton
> Issue Type: Task
> Components: proton-c
>Reporter: Kim van der Riet
>Priority: Major
>
> AMQP encodes arrays with a single element constructor which should be
> identical for all elements in the array. However, if an array of lists is
> constructed in which the first list is empty, then the AMQP empty list
> constructor is used in the array, and the following lists which may be
> non-empty, will not be decoded correctly.
> {noformat}
> >>> import proton
> >>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3],
> >>> ['aaa', 'bbb', 'ccc'])
> >>> d1 = proton.Data()
> >>> d1.put_py_array(a)
> >>> d1.encode().hex()
> 'f0002a000345000a000355015502550300130003a103616161a103626262a103636363'
> {noformat}
> which, when broken down into parts, looks as follows:
> {noformat}
> f0 02a 0003 45 <-- Array constructor, size=0x2a, len=3, type=empty
> list
> ^^--- Empty list constructor
> 000a 0003 5501 5502 5503 <- data for [1,2,3]
> 0013 0003 a103616161 a103626262 a103636363 <-- data for ['aaa',
> 'bbb', 'ccc']
> {noformat}
> When decoded, this is being interpreted as an array of empty lists:
> {noformat}
> >>> d2 = proton.Data()
> >>> d2.decode(d1.encode())
> 10
> >>> d2.get_py_array()
> Array(UNDESCRIBED, 24, [], [], [])
> {noformat}
> When a mis-encoded array is used in the body of a message and is decoded, an
> error results:
> {noformat}
> >>> import proton
> >>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3],
> >>> ['aaa', 'bbb', 'ccc'])
> >>> m1 = proton.Message(body=a)
> >>> m1
> Message(priority=4, body=Array(UNDESCRIBED, 24, [], [1, 2, 3], ['aaa', 'bbb',
> 'ccc']))
> >>> m2 = proton.Message()
> >>> m2.decode(m1.encode())
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
> line 488, in decode
> self._check(pn_message_decode(self._msg, data))
> File
> "/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
> line 87, in _check
> raise exc("[%s]: %s" % (err, pn_error_text(pn_message_error(self._msg
> proton._exceptions.MessageException: [-6]: data error: (null)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2244) [Proton-c] Encoder error for array of lists where first list in array is empty
[
https://issues.apache.org/jira/browse/PROTON-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154899#comment-17154899
]
ASF subversion and git services commented on PROTON-2244:
-
Commit 00d9446248b14ef729162ef52b65a8dd438820cf in qpid-proton's branch
refs/heads/array-of-lists-first-list-empty from Kim van der Riet
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=00d9446 ]
PROTON-2244: Removed array codec tests from Python to C/C++ tests as requested
> [Proton-c] Encoder error for array of lists where first list in array is empty
> --
>
> Key: PROTON-2244
> URL: https://issues.apache.org/jira/browse/PROTON-2244
> Project: Qpid Proton
> Issue Type: Task
> Components: proton-c
>Reporter: Kim van der Riet
>Priority: Major
>
> AMQP encodes arrays with a single element constructor which should be
> identical for all elements in the array. However, if an array of lists is
> constructed in which the first list is empty, then the AMQP empty list
> constructor is used in the array, and the following lists which may be
> non-empty, will not be decoded correctly.
> {noformat}
> >>> import proton
> >>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3],
> >>> ['aaa', 'bbb', 'ccc'])
> >>> d1 = proton.Data()
> >>> d1.put_py_array(a)
> >>> d1.encode().hex()
> 'f0002a000345000a000355015502550300130003a103616161a103626262a103636363'
> {noformat}
> which, when broken down into parts, looks as follows:
> {noformat}
> f0 02a 0003 45 <-- Array constructor, size=0x2a, len=3, type=empty
> list
> ^^--- Empty list constructor
> 000a 0003 5501 5502 5503 <- data for [1,2,3]
> 0013 0003 a103616161 a103626262 a103636363 <-- data for ['aaa',
> 'bbb', 'ccc']
> {noformat}
> When decoded, this is being interpreted as an array of empty lists:
> {noformat}
> >>> d2 = proton.Data()
> >>> d2.decode(d1.encode())
> 10
> >>> d2.get_py_array()
> Array(UNDESCRIBED, 24, [], [], [])
> {noformat}
> When a mis-encoded array is used in the body of a message and is decoded, an
> error results:
> {noformat}
> >>> import proton
> >>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3],
> >>> ['aaa', 'bbb', 'ccc'])
> >>> m1 = proton.Message(body=a)
> >>> m1
> Message(priority=4, body=Array(UNDESCRIBED, 24, [], [1, 2, 3], ['aaa', 'bbb',
> 'ccc']))
> >>> m2 = proton.Message()
> >>> m2.decode(m1.encode())
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
> line 488, in decode
> self._check(pn_message_decode(self._msg, data))
> File
> "/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
> line 87, in _check
> raise exc("[%s]: %s" % (err, pn_error_text(pn_message_error(self._msg
> proton._exceptions.MessageException: [-6]: data error: (null)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2248) [Proton-c] Codec pn_data_vfill() method has symbol and string types interchanged.
[
https://issues.apache.org/jira/browse/PROTON-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-2248:
-
Description:
The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string types
interchanged. The function documentation states:
{noformat}
/* Format codes:
code: AMQP-type (arguments)
...
S: symbol (char*)
s: string (char*)
...
*/
{noformat}
but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
{noformat}
if (code == 'S') {
err = pn_data_put_string(data, pn_bytes(size, start));
} else {
err = pn_data_put_symbol(data, pn_bytes(size, start));
}
{noformat}
Guidance is needed on whether to fix the reversal and keep the stated codes, or
reverse the codes.
was:
The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string types
interchanged. The method documentation states:
{noformat}
/* Format codes:
code: AMQP-type (arguments)
...
S: symbol (char*)
s: string (char*)
...
*/
{noformat}
but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
{noformat}
if (code == 'S') {
err = pn_data_put_string(data, pn_bytes(size, start));
} else {
err = pn_data_put_symbol(data, pn_bytes(size, start));
}
{noformat}
Guidance is needed on whether to fix the reversal and keep the stated codes, or
reverse the codes.
> [Proton-c] Codec pn_data_vfill() method has symbol and string types
> interchanged.
> -
>
> Key: PROTON-2248
> URL: https://issues.apache.org/jira/browse/PROTON-2248
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Major
>
> The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string
> types interchanged. The function documentation states:
> {noformat}
> /* Format codes:
>code: AMQP-type (arguments)
>...
>S: symbol (char*)
>s: string (char*)
>...
> */
> {noformat}
> but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
> {noformat}
> if (code == 'S') {
> err = pn_data_put_string(data, pn_bytes(size, start));
> } else {
> err = pn_data_put_symbol(data, pn_bytes(size, start));
> }
> {noformat}
> Guidance is needed on whether to fix the reversal and keep the stated codes,
> or reverse the codes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1663) system_tests_edge_router fails with ASAN leak
[
https://issues.apache.org/jira/browse/DISPATCH-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1663.
-
Fix Version/s: 1.13.0
Resolution: Duplicate
> system_tests_edge_router fails with ASAN leak
> -
>
> Key: DISPATCH-1663
> URL: https://issues.apache.org/jira/browse/DISPATCH-1663
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.12.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.13.0
>
>
> {noformat}
> 53: ==
> 53: ERROR: test_03_interior_conn_lost
> (system_tests_edge_router.LinkRouteProxyTest)
> 53: --
> 53: Traceback (most recent call last):
> 53: File
> "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_edge_router.py",
> line 1859, in test_03_interior_conn_lost
> 53: er.teardown()
> 53: File "/home/gmurthy/opensource/qpid-dispatch/tests/system_test.py",
> line 442, in teardown
> 53: super(Qdrouterd, self).teardown()
> 53: File "/home/gmurthy/opensource/qpid-dispatch/tests/system_test.py",
> line 295, in teardown
> 53: error("exit code %s, expected %s" % (status, self.expect))
> 53: File "/home/gmurthy/opensource/qpid-dispatch/tests/system_test.py",
> line 285, in error
> 53: self.outfile + '.cmd', f.read()));
> 53: RuntimeError: Process 16556 error: exit code 1, expected 0
> 53: qdrouterd -c Edge1.conf -I /home/gmurthy/opensource/qpid-dispatch/python
> 53:
> /home/gmurthy/opensource/qpid-dispatch/build/tests/system_test.dir/system_tests_edge_router/LinkRouteProxyTest/test_03_interior_conn_lost/Edge1-9.cmd
> 53:
> 53:
> 53: =
> 53: ==16556==ERROR: LeakSanitizer: detected memory leaks
> 53:
> 53: Indirect leak of 704 byte(s) in 1 object(s) allocated from:
> 53: #0 0x7f60c03a3bf5 in __interceptor_posix_memalign
> (/lib64/libasan.so.5+0x10ebf5)
> 53: #1 0x7f60bfb5ace3 in qd_alloc
> /home/gmurthy/opensource/qpid-dispatch/src/alloc_pool.c:347
> 53: #2 0x7f60bfb63e62 in new_qd_buffer_t
> /home/gmurthy/opensource/qpid-dispatch/src/buffer.c:31
> 53: #3 0x7f60bfb641a8 in qd_buffer
> /home/gmurthy/opensource/qpid-dispatch/src/buffer.c:44
> 53: #4 0x7f60bfb64628 in qd_buffer_list_clone
> /home/gmurthy/opensource/qpid-dispatch/src/buffer.c:71
> 53: #5 0x7f60bfbc4d98 in qd_message_copy
> /home/gmurthy/opensource/qpid-dispatch/src/message.c:1030
> 53: #6 0x7f60bfcf9bc9 in qdr_send_to2
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:293
> 53: #7 0x7f60bfcf064f in qdr_management_agent_on_message
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/management_agent.c:534
> 53: #8 0x7f60bfc9f707 in qdr_forward_on_message
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/forwarder.c:310
> 53: #9 0x7f60bfcd7e3c in qdr_general_handler
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:808
> 53: #10 0x7f60bfd7a303 in qd_timer_visit
> /home/gmurthy/opensource/qpid-dispatch/src/timer.c:201
> 53: #11 0x7f60bfd694f5 in handle
> /home/gmurthy/opensource/qpid-dispatch/src/server.c:937
> 53: #12 0x7f60bfd6b153 in thread_run
> /home/gmurthy/opensource/qpid-dispatch/src/server.c:1040
> 53: #13 0x7f60bf7334bf in start_thread (/lib64/libpthread.so.0+0x84bf)
> 53:
> 53: -
> 53: Suppressions used:
> 53: count bytes template
> 53: 5 3008 qd_message_receive
> 53: 2640 qdr_action
> 53: 2760 qdr_core_subscribe
> 53: 1320 qdr_forward_closest_CT
> 53: 2896 qdr_link_deliver
> 53: 1256 qdr_link_issue_credit_CT
> 53: 1192 qdr_delivery_push_CT
> 53:45453371352 *libpython*
> 53: 50788 *python2*
> 53: -
> 53:
> 53: SUMMARY: AddressSanitizer: 704 byte(s) leaked in 1 allocation(s).
> 53:
> 53:
> 53: --
> 53: Ran 90 tests in 240.786s
> 53:
> 53: FAILED (errors=1)
> 1/1 Test #53: system_tests_edge_router .***Failed 240.99 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1661) system_tests_edge_router fails with ASAN leak
[
https://issues.apache.org/jira/browse/DISPATCH-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1661.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> system_tests_edge_router fails with ASAN leak
> -
>
> Key: DISPATCH-1661
> URL: https://issues.apache.org/jira/browse/DISPATCH-1661
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.12.0
>Reporter: Ganesh Murthy
>Priority: Major
> Fix For: 1.13.0
>
>
> {noformat}
> 53: Router EB1 debug dump file:
> 53: alloc.c: Items of type 'qd_timer_t' remain allocated at shutdown: 2
> 53: alloc.c: Items of type 'qd_connector_t' remain allocated at shutdown: 2
> 53: ERROR
> 53:
> 53: ==
> 53: ERROR: tearDownClass (system_tests_edge_router.StreamingMessageTest)
> 53: --
> 53: Traceback (most recent call last):
> 53: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 691, in tearDownClass
> 53: cls.tester.teardown()
> 53: File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py",
> line 637, in teardown
> 53: raise RuntimeError("Errors during teardown: \n\n%s" %
> "\n\n".join([str(e) for e in errors]))
> 53: RuntimeError: Errors during teardown:
> 53:
> 53: Process 14572 error: exit code 23, expected 0
> 53: qdrouterd -c EA1.conf -I /home/travis/build/apache/qpid-dispatch/python
> 53:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_edge_router/StreamingMessageTest/setUpClass/EA1-18.cmd
> 53:
> 53:
> 53: =
> 53: ==14572==ERROR: LeakSanitizer: detected memory leaks
> 53:
> 53: Indirect leak of 7488 byte(s) in 13 object(s) allocated from:
> 53: #0 0x7fdea74bb076 in __interceptor_posix_memalign
> (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99076)
> 53: #1 0x7fdea6d95d28 in qd_alloc
> /home/travis/build/apache/qpid-dispatch/src/alloc_pool.c:347
> 53: #2 0x7fdea6d9fddd in qd_buffer
> /home/travis/build/apache/qpid-dispatch/src/buffer.c:44
> 53: #3 0x7fdea6ea7b8a in qdr_field
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:255
> 53: #4 0x7fdea6ec331f in qdr_terminus
> /home/travis/build/apache/qpid-dispatch/src/router_core/terminus.c:47
> 53: #5 0x7fdea6efd6dd in AMQP_link_attach_handler
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:866
> 53: #6 0x7fdea6f13674 in handle
> /home/travis/build/apache/qpid-dispatch/src/server.c:1015
> 53: #7 0x7fdea6f1919f in thread_run
> /home/travis/build/apache/qpid-dispatch/src/server.c:1040
> 53: #8 0x7fdea69236b9 in start_thread
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
> 53:
> 53: -
> 53: Suppressions used:
> 53: count bytes template
> 53: 18 10944 qd_core_agent_query_handler
> 53: 73 41536 qd_message_receive
> 53: 13 7488 qdr_connection_opened
> 53: 15 8120 qdr_core_subscribe
> 53: 1192 qdr_link_deliver
> 53:3311244 *libpython*
> 53: 37120 *python2*
> 53: -
> 53:
> 53: SUMMARY: AddressSanitizer: 7488 byte(s) leaked in 13 allocation(s).
> 53:
> 53:
> 53: --
> 53: Ran 90 tests in 241.217s
> 53:
> 53: FAILED (errors=1)53/66 Test #53: system_tests_edge_router
> ..***Failed 241.32 sec {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2248) [Proton-c] Codec pn_data_vfill() method has symbol and string types interchanged.
Kim van der Riet created PROTON-2248:
Summary: [Proton-c] Codec pn_data_vfill() method has symbol and
string types interchanged.
Key: PROTON-2248
URL: https://issues.apache.org/jira/browse/PROTON-2248
Project: Qpid Proton
Issue Type: Bug
Reporter: Kim van der Riet
The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string types
interchanged. The method documentation states:
{noformat}
/* Format codes:
code: AMQP-type (arguments)
...
S: symbol (char*)
s: string (char*)
...
*/
{noformat}
but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
{noformat}
if (code == 'S') {
err = pn_data_put_string(data, pn_bytes(size, start));
} else {
err = pn_data_put_symbol(data, pn_bytes(size, start));
}
{noformat}
Guidance is needed on whether to fix the reversal and keep the stated codes, or
reverse the codes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-335) Need a means of specifying and reading link properties
[ https://issues.apache.org/jira/browse/PROTON-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154674#comment-17154674 ] ASF GitHub Bot commented on PROTON-335: --- jiridanek commented on pull request #260: URL: https://github.com/apache/qpid-proton/pull/260#issuecomment-656195451 I guess this is good. It looks similar to other such "accessor" code, and there is a C test and a Python test for this. CC @astitcher This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Need a means of specifying and reading link properties > -- > > Key: PROTON-335 > URL: https://issues.apache.org/jira/browse/PROTON-335 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-0.4, proton-c-0.29.0 >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Minor > Labels: api > Fix For: proton-c-0.32.0 > > > There are some cases where it may be beneficial to use link properties (since > link capabilities do not allow for key-value pairs, they can't easily convey > a desired configurable value and the properties on a terminus refer to the > dynamically created node not the link or the terminus itself). > (I've set this to minor since major feels a little strong, but I do think its > important ultimately for the engine to expose all the extension points from > the protocol.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on pull request #260: PROTON-335: Add access to link attach properties (C and Python)
jiridanek commented on pull request #260: URL: https://github.com/apache/qpid-proton/pull/260#issuecomment-656195451 I guess this is good. It looks similar to other such "accessor" code, and there is a C test and a Python test for this. CC @astitcher This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek merged pull request #262: PROTON-2235 set threaderciser test timeout and modernize compilation
jiridanek merged pull request #262: URL: https://github.com/apache/qpid-proton/pull/262 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2235) CTest timeouts are too large to be useful on Travis CI
[
https://issues.apache.org/jira/browse/PROTON-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154668#comment-17154668
]
ASF subversion and git services commented on PROTON-2235:
-
Commit 2cd9522d175d8814f4964b7e77407b8257c09fff in qpid-proton's branch
refs/heads/master from Jiri Daněk
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=2cd9522 ]
PROTON-2235 set threaderciser test timeout and modernize compilation (#262)
> CTest timeouts are too large to be useful on Travis CI
> --
>
> Key: PROTON-2235
> URL: https://issues.apache.org/jira/browse/PROTON-2235
> Project: Qpid Proton
> Issue Type: Test
>Affects Versions: proton-c-0.31.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://travis-ci.org/github/apache/qpid-proton/jobs/693871917
> The timeouts of 1500s are too large and do not step in before Travis timeout
> kills the entire job:
> {noformat}
> 6: Test command: /opt/pyenv/shims/python
> "/home/travis/build/apache/qpid-proton/scripts/env.py" "--"
> "TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
> --error-exitcode=42 --quiet
> --suppressions=/home/travis/build/apache/qpid-proton/tests/valgrind.supp"
> "/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full"
> "--error-exitcode=42" "--quiet"
> "--suppressions=/home/travis/build/apache/qpid-proton/tests/valgrind.supp"
> "/home/travis/build/apache/qpid-proton/build/c/tests/c-threaderciser"
> 6: Test timeout computed to be: 1500
> 6: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
> connect, close-connect, wake, timeout, cancel-timeout]
> No output has been received in the last 10m0s, this potentially indicates a
> stalled build or something wrong with the build itself.
> Check the details on how to adjust your build configuration on:
> https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2235) CTest timeouts are too large to be useful on Travis CI
[
https://issues.apache.org/jira/browse/PROTON-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154669#comment-17154669
]
ASF GitHub Bot commented on PROTON-2235:
jiridanek merged pull request #262:
URL: https://github.com/apache/qpid-proton/pull/262
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CTest timeouts are too large to be useful on Travis CI
> --
>
> Key: PROTON-2235
> URL: https://issues.apache.org/jira/browse/PROTON-2235
> Project: Qpid Proton
> Issue Type: Test
>Affects Versions: proton-c-0.31.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://travis-ci.org/github/apache/qpid-proton/jobs/693871917
> The timeouts of 1500s are too large and do not step in before Travis timeout
> kills the entire job:
> {noformat}
> 6: Test command: /opt/pyenv/shims/python
> "/home/travis/build/apache/qpid-proton/scripts/env.py" "--"
> "TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
> --error-exitcode=42 --quiet
> --suppressions=/home/travis/build/apache/qpid-proton/tests/valgrind.supp"
> "/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full"
> "--error-exitcode=42" "--quiet"
> "--suppressions=/home/travis/build/apache/qpid-proton/tests/valgrind.supp"
> "/home/travis/build/apache/qpid-proton/build/c/tests/c-threaderciser"
> 6: Test timeout computed to be: 1500
> 6: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
> connect, close-connect, wake, timeout, cancel-timeout]
> No output has been received in the last 10m0s, this potentially indicates a
> stalled build or something wrong with the build itself.
> Check the details on how to adjust your build configuration on:
> https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2247) [c] Proactor API to support 'raw' TCP connections using the proactor event loop
Andrew Stitcher created PROTON-2247: --- Summary: [c] Proactor API to support 'raw' TCP connections using the proactor event loop Key: PROTON-2247 URL: https://issues.apache.org/jira/browse/PROTON-2247 Project: Qpid Proton Issue Type: New Feature Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.32.0 There are applications that use amqp together with some other protocol (http for example). It is currently difficult to combine other TCP use with amqp use when using proton and the proactor. It will be useful to be able to combine using 'raw' TCP connections with AMQP connections in a single proactor event loop. This will allow you to write application combining multiple protocols with AMQP without having to use multiple event loops and hence probably threads. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2246) Restructure pn_netaddr_* implementation
Andrew Stitcher created PROTON-2246: --- Summary: Restructure pn_netaddr_* implementation Key: PROTON-2246 URL: https://issues.apache.org/jira/browse/PROTON-2246 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.32.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8452) Message larger than 2GB
Tomas Soltys created QPID-8452: -- Summary: Message larger than 2GB Key: QPID-8452 URL: https://issues.apache.org/jira/browse/QPID-8452 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-8.0.0 Reporter: Tomas Soltys Seems like there is a 2GB limitation for how big the message can be. This is most likely due to usage of Int type. Also, when this limit is reached no exception is raised nor any message is printed into a broker log and sender seems to keep waiting for acknowledgement. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2245) Logging issues in messenger.c
Dirk Craeynest created PROTON-2245:
--
Summary: Logging issues in messenger.c
Key: PROTON-2245
URL: https://issues.apache.org/jira/browse/PROTON-2245
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.31.0
Reporter: Dirk Craeynest
With the new QPID Proton library 0.31 to which we upgraded, the application can
control the logging via the subsystem and severity masks of the loggers
(typically by modifying the setup of the pn_default_logger at startup).
So, for example, we find in file memory.c:
if (PN_SHOULD_LOG(logger, PN_SUBSYSTEM_MEMORY, PN_LEVEL_DEBUG)) {
pn_logger_logf(logger, PN_SUBSYSTEM_MEMORY, PN_LEVEL_DEBUG, "Memory
allocation stats:");
...
and the macro PN_SHOULD_LOG will verify (fast) that the call to pn_logger_logf
is to be done, when trace is really desired.
But we have calls that do not have this 'if', e.g. in messenger.c, we have:
case PN_CONNECTION_INIT:
pn_logf("connection created: %p", (void *) pn_event_connection(event));
break;
where pn_logf is a macro:
#define pn_logf(...) \
do { \
if (pni_log_enabled()) \
pni_logf_impl(__VA_ARGS__); \
} while(0)
where pni_log_enabled will just return a boolean (true if logging was enabled).
Then pni_logf_impl is called,
which then calls pni_vlogf_impl,
which then calls
pni_logger_vlogf(pn_default_logger(), PN_SUBSYSTEM_ALL, PN_LEVEL_TRACE, fmt,
ap);
which then formats the string and calls
pni_logger_log(logger, subsystem, severity, pn_string_get(logger->scratch));
which then unconditionally calls the logger->sink
(and the default sink of the pn_default_logger unconditionally writes the msg.
It looks to us that the call to pni_log_enabled() in pn_logf should in fact be
something like:
if (PN_SHOULD_LOG(logger, PN_SUBSYSTEM_ALL, PN_LEVEL_TRACE)) { \
pni_logf_impl(__VA_ARGS__); \
so as to have a consistent logging control.
Currently, it looks like the logging done via pn_logf is using an alternate
mechanism than the central mechanism.
As far as we can see, only messenger.c contains such pn_logf "unprotected"
calls ...
So messenger.c should likely be converted to the new way to log things.
Extra logging issues, all in messenger.c:
Some calls to pn_logf are done when the level should be error, but as pn_logf
is called, the severity is hardcoded to TRACE. See pn_error_report in
messenger.c
Most of the errors are *not* traced, they are just stored in the messenger.
One could have expected that when logging of ERROR level is asked, that any
error would be logged.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
