[jira] [Created] (QPID-8522) Intermittent unit test failure on Travis
Chris Richardson created QPID-8522: -- Summary: Intermittent unit test failure on Travis Key: QPID-8522 URL: https://issues.apache.org/jira/browse/QPID-8522 Project: Qpid Issue Type: Bug Affects Versions: qpid-cpp-1.40.0 Reporter: Chris Richardson Fix For: qpid-cpp-1.40.0 Attachments: Travis unit test failure.txt Travis reports attached text -- 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-8521) Assignment in comparison at Translation.cpp:233
Chris Richardson created QPID-8521: -- Summary: Assignment in comparison at Translation.cpp:233 Key: QPID-8521 URL: https://issues.apache.org/jira/browse/QPID-8521 Project: Qpid Issue Type: Bug Affects Versions: qpid-cpp-1.40.0 Reporter: Chris Richardson Fix For: qpid-cpp-1.40.0 Compiler reports: src/qpid/broker/amqp/Translation.cpp:233:45: warning: suggest parentheses around assignment used as truth value [-Wparentheses] 233 | assert(cid.value.bytes.size = 16); -- 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] [Comment Edited] (QPID-8517) Run Travis CI separately under python2 and python3 evironments
[ https://issues.apache.org/jira/browse/QPID-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318880#comment-17318880 ] Chris Richardson edited comment on QPID-8517 at 4/11/21, 4:56 PM: -- Sincere apologies for the enormous amount of spam to the dev channel from this issue today! It's a bit hard to test Travis without using the real thing though. The good news is that it's not entirely in vain - I believe I've got the CI build to do something sensible by only the 48th build of my feature branch! [https://www.travis-ci.com/github/apache/qpid-cpp/builds/222743206] That build shows 2 parallel tasks, one building on Ubuntu bionic with a mixed python2/3 environment and the other building on Focal (which is pure python3) and failing due to this bug with a PR in flight: QPID-8516. Note that I've added a line to .travis.yaml to print the available python versions installed by the pyenv package in addition to the system ones, which for focal still shows only python3 versions. [~jdanek] I'm all for a docker solution if you think it's viable, otherwise I think this setup will do the trick. Caveat: since the build fails early due to QPID-8516 I'm not sure whether the tests will fail, since they might need qpid-python (which is a python2 package?). I'll cherry-pick that fix into this branch, then we'll know where we stand. was (Author: crichardson): Sincere apologies for the enormous amount of spam to the dev channel from this issue today! It's a bit hard to test Travis without using the real thing though. The good news is that it's not entirely in vain - I believe I've got the CI build to do something sensible by only the 48th build of my feature branch! [https://www.travis-ci.com/github/apache/qpid-cpp/builds/222743206] That build shows 2 parallel tasks, one building on Ubuntu bionic with a mixed python2/3 environment and the other building on Focal (which is pure python3) and failing due to this bug with a PR in flight: QPID-8516. Note that I've added a line to .travis.yaml to print the available python versions installed by the pyenv package in addition to the system ones, which for focal still shows only python3 versions. [~jdanek] I'm all for a docker solution if you think it's viable, otherwise I think this setup will do the trick. Caveat: since the build fails early due to QPID-8516 I'm not sure whether the tests will fail, since they might need qpid-python (which is a python2 package?). I'll merge the PR for that fix and rebase this branch, then we'll know where we stand. > Run Travis CI separately under python2 and python3 evironments > -- > > Key: QPID-8517 > URL: https://issues.apache.org/jira/browse/QPID-8517 > Project: Qpid > Issue Type: Improvement >Affects Versions: qpid-cpp-1.39.0 > Environment: Travis/Xenial >Reporter: Chris Richardson >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > While mixed python versions are supported in the build system, it would be > good to verify that the codebase can be built and unit tests run under both > python2 and python3 environments. > Travis can (?) be configured to do this in parallel by running the tests > having installed the "python-dev" apt package (python2) or "python3-dev" > package for python3 (Xenial). > > -- 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] (QPID-8517) Run Travis CI separately under python2 and python3 evironments
[ https://issues.apache.org/jira/browse/QPID-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318880#comment-17318880 ] Chris Richardson commented on QPID-8517: Sincere apologies for the enormous amount of spam to the dev channel from this issue today! It's a bit hard to test Travis without using the real thing though. The good news is that it's not entirely in vain - I believe I've got the CI build to do something sensible by only the 48th build of my feature branch! [https://www.travis-ci.com/github/apache/qpid-cpp/builds/222743206] That build shows 2 parallel tasks, one building on Ubuntu bionic with a mixed python2/3 environment and the other building on Focal (which is pure python3) and failing due to this bug with a PR in flight: QPID-8516. Note that I've added a line to .travis.yaml to print the available python versions installed by the pyenv package in addition to the system ones, which for focal still shows only python3 versions. [~jdanek] I'm all for a docker solution if you think it's viable, otherwise I think this setup will do the trick. Caveat: since the build fails early due to QPID-8516 I'm not sure whether the tests will fail, since they might need qpid-python (which is a python2 package?). I'll merge the PR for that fix and rebase this branch, then we'll know where we stand. > Run Travis CI separately under python2 and python3 evironments > -- > > Key: QPID-8517 > URL: https://issues.apache.org/jira/browse/QPID-8517 > Project: Qpid > Issue Type: Improvement >Affects Versions: qpid-cpp-1.39.0 > Environment: Travis/Xenial >Reporter: Chris Richardson >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > While mixed python versions are supported in the build system, it would be > good to verify that the codebase can be built and unit tests run under both > python2 and python3 environments. > Travis can (?) be configured to do this in parallel by running the tests > having installed the "python-dev" apt package (python2) or "python3-dev" > package for python3 (Xenial). > > -- 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-8517) Run Travis CI separately under python2 and python3 evironments
Chris Richardson created QPID-8517: -- Summary: Run Travis CI separately under python2 and python3 evironments Key: QPID-8517 URL: https://issues.apache.org/jira/browse/QPID-8517 Project: Qpid Issue Type: Improvement Affects Versions: qpid-cpp-1.39.0 Environment: Travis/Xenial Reporter: Chris Richardson Fix For: qpid-cpp-1.40.0 While mixed python versions are supported in the build system, it would be good to verify that the codebase can be built and unit tests run under both python2 and python3 environments. Travis can (?) be configured to do this in parallel by running the tests having installed the "python-dev" apt package (python2) or "python3-dev" package for python3 (Xenial). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8516) Python excerpts in CMakeFiles are python2
[
https://issues.apache.org/jira/browse/QPID-8516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8516:
---
Component/s: C++ Broker
> Python excerpts in CMakeFiles are python2
> -
>
> Key: QPID-8516
> URL: https://issues.apache.org/jira/browse/QPID-8516
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.39.0
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.40.0
>
>
> CMake fails on python3-only systems with
> {quote}-- Found PythonInterp: /usr/bin/python (found suitable version
> "3.8.8", minimum required is "2.7")
> -- Found PythonInterp: /usr/bin/python (found version "3.8.8")
> File "", line 1
> from distutils.sysconfig import get_python_lib; print get_python_lib(False,
> prefix='/usr/local').replace('\\', '/')
> ^
> SyntaxError: invalid syntax
> CMake Error at managementgen/CMakeLists.txt:34 (install):
> install DIRECTORY given no DESTINATION!
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8516) Python excerpts in CMakeFiles are python2
[
https://issues.apache.org/jira/browse/QPID-8516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8516:
---
Description:
CMake fails on python3-only systems with
{quote}-- Found PythonInterp: /usr/bin/python (found suitable version "3.8.8",
minimum required is "2.7")
-- Found PythonInterp: /usr/bin/python (found version "3.8.8")
File "", line 1
from distutils.sysconfig import get_python_lib; print get_python_lib(False,
prefix='/usr/local').replace('\\', '/')
^
SyntaxError: invalid syntax
CMake Error at managementgen/CMakeLists.txt:34 (install):
install DIRECTORY given no DESTINATION!
{quote}
was:
> Python excerpts in CMakeFiles are python2
> -
>
> Key: QPID-8516
> URL: https://issues.apache.org/jira/browse/QPID-8516
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-cpp-1.39.0
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.40.0
>
>
> CMake fails on python3-only systems with
> {quote}-- Found PythonInterp: /usr/bin/python (found suitable version
> "3.8.8", minimum required is "2.7")
> -- Found PythonInterp: /usr/bin/python (found version "3.8.8")
> File "", line 1
> from distutils.sysconfig import get_python_lib; print get_python_lib(False,
> prefix='/usr/local').replace('\\', '/')
> ^
> SyntaxError: invalid syntax
> CMake Error at managementgen/CMakeLists.txt:34 (install):
> install DIRECTORY given no DESTINATION!
> {quote}
>
--
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-8516) Python excerpts in CMakeFiles are python2
Chris Richardson created QPID-8516: -- Summary: Python excerpts in CMakeFiles are python2 Key: QPID-8516 URL: https://issues.apache.org/jira/browse/QPID-8516 Project: Qpid Issue Type: Bug Affects Versions: qpid-cpp-1.39.0 Reporter: Chris Richardson Fix For: qpid-cpp-1.40.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8390) FindProton.cmake uses incorrect search paths for non-installed Proton
[ https://issues.apache.org/jira/browse/QPID-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-8390: --- Fix Version/s: qpid-cpp-1.40.0 > FindProton.cmake uses incorrect search paths for non-installed Proton > - > > Key: QPID-8390 > URL: https://issues.apache.org/jira/browse/QPID-8390 > Project: Qpid > Issue Type: Bug > Environment: Ubuntu, gcc9 >Reporter: Chris Richardson >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > This CMake script looks for proton library components under a "proton-c" > subdirectory instead of just "c" as it now is. -- 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-8390) FindProton.cmake uses incorrect search paths for non-installed Proton
Chris Richardson created QPID-8390: -- Summary: FindProton.cmake uses incorrect search paths for non-installed Proton Key: QPID-8390 URL: https://issues.apache.org/jira/browse/QPID-8390 Project: Qpid Issue Type: Bug Environment: Ubuntu, gcc9 Reporter: Chris Richardson This CMake script looks for proton library components under a "proton-c" subdirectory instead of just "c" as it now is. -- 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-8251) Fail unit tests with more friendly output if the boost-test library is not present
Chris Richardson created QPID-8251:
--
Summary: Fail unit tests with more friendly output if the
boost-test library is not present
Key: QPID-8251
URL: https://issues.apache.org/jira/browse/QPID-8251
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Affects Versions: qpid-cpp-1.39.0
Reporter: Chris Richardson
If the boost-test library is not present, cmake logs a warning:
"-- Could not find unit testing library - will not build unit tests"
(see https://issues.apache.org/jira/browse/QPID-5260)
This is easy to miss and leads to a failure in the unit tests with some rather
ugly output (see test output below) due to the unit_tests binary and indeed
entire make target not being created.
Those unfamiliar with the testing framework (like me) may spend quite some time
connecting the resulting "valgrind: unit_test: command not found" error message
to the above cmake warning, so it might be nice to have eg: the
"run_unit_tests" script output an additional message explaining the probable
cause.
Test output:
{{run_unit_tests: Calling '/usr/bin/valgrind --leak-check=full --num-callers=25
--error-exitcode=100
--log-file=/home/chrisr/projects/git/qpid-cpp/build-1.39.0-rc1/run_unit_tests_d578/valgrind_4832.log
--gen-suppressions=all
--suppressions=/home/chrisr/projects/git/qpid-cpp/build-1.39.0-rc1/src/tests/.valgrind.supp
-- unit_test'}}
{{valgrind: unit_test: command not found}}
{{Traceback (most recent call last):}}
{{ File "run_unit_tests", line 37, in }}
{{ call_with_valgrind("unit_test")}}
{{ File
"/home/chrisr/projects/git/qpid-cpp/build-1.39.0-rc1/src/tests/common.py", line
70, in call_with_valgrind}}
{{ call(command, *args, **kwargs)}}
{{ File
"/home/chrisr/projects/git/qpid-cpp/build-1.39.0-rc1/src/tests/plano.py", line
418, in call}}
{{ _subprocess.check_call(command, **kwargs)}}
{{ File "/usr/lib/python2.7/subprocess.py", line 190, in check_call}}
{{ raise CalledProcessError(retcode, cmd)}}
{{subprocess.CalledProcessError: Command '/usr/bin/valgrind --leak-check=full
--num-callers=25 --error-exitcode=100
--log-file=/home/chrisr/projects/git/qpid-cpp/build-1.39.0-rc1/run_unit_tests_d578/valgrind_4832.log
--gen-suppressions=all
--suppressions=/home/chrisr/projects/git/qpid-cpp/build-1.39.0-rc1/src/tests/.valgrind.supp
-- unit_test' returned non-zero exit status 127}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8211) [legacystore] Place deprecation warnings in cmake and in log when starting
[ https://issues.apache.org/jira/browse/QPID-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518283#comment-16518283 ] Chris Richardson commented on QPID-8211: I hope you mean "legacystore" ;) > [legacystore] Place deprecation warnings in cmake and in log when starting > -- > > Key: QPID-8211 > URL: https://issues.apache.org/jira/browse/QPID-8211 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > After a discussion on the users list, it has been decided to place > deprecation notices in the cmake scripts and in the log files at WARNING > level when the linearstore module is loaded on broker start. The linearstore > will be removed from the source code tree at some point in the > not-too-distant future (perhaps six months or so). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8200) [linearstore] Compile error when compiling on Fedora 28
[
https://issues.apache.org/jira/browse/QPID-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494305#comment-16494305
]
Chris Richardson commented on QPID-8200:
I've also seen this problem on recent Gentoo versions due to the upgrade to gcc
8.x. Unfortunately I missed it in my previous round of gcc 8 fixes because I
forgot to include the optional linear store component :{
IIRC a fix is also required for the legacystore component - perhaps these could
be fixed under the same issue since I think the fixes will be very similar.
> [linearstore] Compile error when compiling on Fedora 28
> ---
>
> Key: QPID-8200
> URL: https://issues.apache.org/jira/browse/QPID-8200
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> When compiling on Fedora 28, a compile warning {{-Werror=class-memaccess}} is
> seen when compiling {{qpid::linearstore::journal::pmgr}} , and which was not
> seen on Fedora 27:
> {noformat}
> qpid::linearstore::journal::pmgr::initialize(qpid::linearstore::journal::aio_callback*,
> uint32_t, uint16_t)':
> /foo/cpp/src/qpid/linearstore/journal/pmgr.cpp:115:68: error: 'void*
> memset(void*, int, size_t)' clearing an object of non-trivial type 'struct
> qpid::linearstore::journal::pmgr::page_cb'; use assignment instead
> [-Werror=class-memaccess]
> std::memset(_page_cb_arr, 0, _cache_num_pages * sizeof(page_cb));
> ^
> In file included from /foo/cpp/src/qpid/linearstore/journal/pmgr.cpp:22:
> /foo/cpp/src/qpid/linearstore/journal/pmgr.h:63:12: note: 'struct
> qpid::linearstore::journal::pmgr::page_cb' declared here
> struct page_cb
> ^~~
> cc1plus: all warnings being treated as errors{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8188) Invalid type qualifiers causes build failure on GCC 8
Chris Richardson created QPID-8188:
--
Summary: Invalid type qualifiers causes build failure on GCC 8
Key: QPID-8188
URL: https://issues.apache.org/jira/browse/QPID-8188
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: qpid-cpp-1.38.0
Environment: Gentoo x64, GCC 8.1
Reporter: Chris Richardson
Fix For: qpid-cpp-1.39.0
[ 30%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/Dispatcher.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/log/Statement.cpp: In
static member function ‘static qpid::log::Category
qpid::log::CategoryFileNameHints::categoryOf(const char*)’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/log/Statement.cpp:121:50:
error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers]
if (strstr(fName, (const char* const)it->first) != 0) {
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8186) Incorrect exception handling fails to build on GCC 8
[
https://issues.apache.org/jira/browse/QPID-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8186:
---
Component/s: C++ Broker
> Incorrect exception handling fails to build on GCC 8
>
>
> Key: QPID-8186
> URL: https://issues.apache.org/jira/browse/QPID-8186
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.38.0
> Environment: Gentoo x64, GCC 8.1
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> [ 22%] Building CXX object
> src/CMakeFiles/qpidcommon.dir/qpid/sys/ssl/check.cpp.o
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:
> In member function ‘bool qpid::sys::SocketAddress::isComparable(const
> qpid::sys::SocketAddress&) const’:
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:208:18:
> error: catching polymorphic type ‘class qpid::Exception’ by value
> [-Werror=catch-value=]
> } catch (Exception) {
> ^
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:212:14:
> error: catching polymorphic type ‘class qpid::Exception’ by value
> [-Werror=catch-value=]
> } catch (Exception) {
> ^
>
>
> these "catch (Exception)" statements would better be const ref, which would
> also fix the build failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8187) Incompatible callback function pointer casts fail to build on GCC 8
[
https://issues.apache.org/jira/browse/QPID-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8187:
---
Component/s: C++ Broker
> Incompatible callback function pointer casts fail to build on GCC 8
> ---
>
> Key: QPID-8187
> URL: https://issues.apache.org/jira/browse/QPID-8187
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.38.0
> Environment: Gentoo x64, GCC 8.1
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> {quote}[ 22%] Building CXX object
> src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
> constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
> string&, const string&, int, int, bool)’:
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
> error: cast between incompatible function types from ‘int (*)(void*, int,
> const char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
> callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
> ^~~
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
> error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
> void*, int, sasl_secret_t**)’
> Unknown macro: \{aka ‘int (*)(sasl_conn*, void*, int, sasl_secret**)’}
> to ‘int (*)()’ [-Werror=cast-function-type]
> callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
> ^~
> {quote}
> Given the constrains of the SASL library interface, the only obvious solution
> for this I can think of is to add "-Wno-error=cast-function-type" to the
> compiler settings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8187) Incompatible callback function pointer casts fail to build on GCC 8
[
https://issues.apache.org/jira/browse/QPID-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8187:
---
Description:
{quote}[ 22%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
string&, const string&, int, int, bool)’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
error: cast between incompatible function types from ‘int (*)(void*, int, const
char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
^~~
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
void*, int, sasl_secret_t**)’
Unknown macro: \{aka ‘int (*)(sasl_conn*, void*, int, sasl_secret**)’}
to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
^~
{quote}
Given the constrains of the SASL library interface, the only obvious solution
for this I can think of is to add "-Wno-error=cast-function-type" to the
compiler settings.
was:
{quote}[ 22%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
string&, const string&, int, int, bool)’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
error: cast between incompatible function types from ‘int (*)(void*, int, const
char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
^~~
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
void*, int, sasl_secret_t**)’ {aka ‘int (*)(sasl_conn*, void*, int,
sasl_secret**)’} to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
^~
{quote}
Given the constrains of the SASL library interface, the only obvious solution
for this I can think of is to add "-Wno-error=cast-function-type" to the
compiler settings.
> Incompatible callback function pointer casts fail to build on GCC 8
> ---
>
> Key: QPID-8187
> URL: https://issues.apache.org/jira/browse/QPID-8187
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-cpp-1.38.0
> Environment: Gentoo x64, GCC 8.1
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> {quote}[ 22%] Building CXX object
> src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
> constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
> string&, const string&, int, int, bool)’:
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
> error: cast between incompatible function types from ‘int (*)(void*, int,
> const char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
> callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
> ^~~
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
> error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
> void*, int, sasl_secret_t**)’
> Unknown macro: \{aka ‘int (*)(sasl_conn*, void*, int, sasl_secret**)’}
> to ‘int (*)()’ [-Werror=cast-function-type]
> callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
> ^~
> {quote}
> Given the constrains of the SASL library interface, the only obvious solution
> for this I can think of is to add "-Wno-error=cast-function-type" to the
> compiler settings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8187) Incompatible callback function pointer casts fail to build on GCC 8
[
https://issues.apache.org/jira/browse/QPID-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8187:
---
Environment: Gentoo x64, GCC 8.1 (was: Gentoo x64)
Description:
{quote}[ 22%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
string&, const string&, int, int, bool)’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
error: cast between incompatible function types from ‘int (*)(void*, int, const
char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
^~~
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
void*, int, sasl_secret_t**)’ {aka ‘int (*)(sasl_conn*, void*, int,
sasl_secret**)’} to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
^~
{quote}
Given the constrains of the SASL library interface, the only obvious solution
for this I can think of is to add "-Wno-error=cast-function-type" to the
compiler settings.
was:
[ 22%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
string&, const string&, int, int, bool)’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
error: cast between incompatible function types from ‘int (*)(void*, int, const
char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
^~~
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
void*, int, sasl_secret_t**)’ \{aka ‘int (*)(sasl_conn*, void*, int,
sasl_secret**)’} to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
^~~
Given the constrains of the SASL library interface, the only obvious solution
for this I can think of is to add "-Wno-error=cast-function-type" to the
compiler settings.
> Incompatible callback function pointer casts fail to build on GCC 8
> ---
>
> Key: QPID-8187
> URL: https://issues.apache.org/jira/browse/QPID-8187
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-cpp-1.38.0
> Environment: Gentoo x64, GCC 8.1
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> {quote}[ 22%] Building CXX object
> src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
> constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
> string&, const string&, int, int, bool)’:
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
> error: cast between incompatible function types from ‘int (*)(void*, int,
> const char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
> callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
> ^~~
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
> error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
> void*, int, sasl_secret_t**)’ {aka ‘int (*)(sasl_conn*, void*, int,
> sasl_secret**)’} to ‘int (*)()’ [-Werror=cast-function-type]
> callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
> ^~
> {quote}
> Given the constrains of the SASL library interface, the only obvious solution
> for this I can think of is to add "-Wno-error=cast-function-type" to the
> compiler settings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8186) Incorrect exception handling fails to build on GCC 8
[
https://issues.apache.org/jira/browse/QPID-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPID-8186:
---
Environment: Gentoo x64, GCC 8.1 (was: Gentoo x64)
> Incorrect exception handling fails to build on GCC 8
>
>
> Key: QPID-8186
> URL: https://issues.apache.org/jira/browse/QPID-8186
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-cpp-1.38.0
> Environment: Gentoo x64, GCC 8.1
>Reporter: Chris Richardson
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> [ 22%] Building CXX object
> src/CMakeFiles/qpidcommon.dir/qpid/sys/ssl/check.cpp.o
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:
> In member function ‘bool qpid::sys::SocketAddress::isComparable(const
> qpid::sys::SocketAddress&) const’:
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:208:18:
> error: catching polymorphic type ‘class qpid::Exception’ by value
> [-Werror=catch-value=]
> } catch (Exception) {
> ^
> /home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:212:14:
> error: catching polymorphic type ‘class qpid::Exception’ by value
> [-Werror=catch-value=]
> } catch (Exception) {
> ^
>
>
> these "catch (Exception)" statements would better be const ref, which would
> also fix the build failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8187) Incompatible callback function pointer casts fail to build on GCC 8
Chris Richardson created QPID-8187:
--
Summary: Incompatible callback function pointer casts fail to
build on GCC 8
Key: QPID-8187
URL: https://issues.apache.org/jira/browse/QPID-8187
Project: Qpid
Issue Type: Bug
Affects Versions: qpid-cpp-1.38.0
Environment: Gentoo x64
Reporter: Chris Richardson
Fix For: qpid-cpp-1.39.0
[ 22%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/epoll/EpollPoller.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp: In
constructor ‘qpid::CyrusSasl::CyrusSasl(const string&, const string&, const
string&, const string&, int, int, bool)’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:215:46:
error: cast between incompatible function types from ‘int (*)(void*, int, const
char**, unsigned int*)’ to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getUserFromSettings;
^~~
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/SaslFactory.cpp:223:50:
error: cast between incompatible function types from ‘int (*)(sasl_conn_t*,
void*, int, sasl_secret_t**)’ \{aka ‘int (*)(sasl_conn*, void*, int,
sasl_secret**)’} to ‘int (*)()’ [-Werror=cast-function-type]
callbacks[i].proc = (CallbackProc*) &getPasswordFromSettings;
^~~
Given the constrains of the SASL library interface, the only obvious solution
for this I can think of is to add "-Wno-error=cast-function-type" to the
compiler settings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8186) Incorrect exception handling fails to build on GCC 8
Chris Richardson created QPID-8186:
--
Summary: Incorrect exception handling fails to build on GCC 8
Key: QPID-8186
URL: https://issues.apache.org/jira/browse/QPID-8186
Project: Qpid
Issue Type: Bug
Affects Versions: qpid-cpp-1.38.0
Environment: Gentoo x64
Reporter: Chris Richardson
Fix For: qpid-cpp-1.39.0
[ 22%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/sys/ssl/check.cpp.o
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:
In member function ‘bool qpid::sys::SocketAddress::isComparable(const
qpid::sys::SocketAddress&) const’:
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:208:18:
error: catching polymorphic type ‘class qpid::Exception’ by value
[-Werror=catch-value=]
} catch (Exception) {
^
/home/chrisr/projects/qpid/qpid-cpp/source/src/qpid/sys/posix/SocketAddress.cpp:212:14:
error: catching polymorphic type ‘class qpid::Exception’ by value
[-Werror=catch-value=]
} catch (Exception) {
^
these "catch (Exception)" statements would better be const ref, which would
also fix the build failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8050) CMake reports CMP0022
Chris Richardson created QPID-8050:
--
Summary: CMake reports CMP0022
Key: QPID-8050
URL: https://issues.apache.org/jira/browse/QPID-8050
Project: Qpid
Issue Type: Improvement
Affects Versions: qpid-cpp-1.37.0
Environment: Ubuntu 17, cmake version 3.9.1
Reporter: Chris Richardson
Fix For: qpid-cpp-1.38.0
CMake output:
{quote} CMake Deprecation Warning at CMakeLists.txt:138 (cmake_policy):
The OLD behavior for policy CMP0022 will be removed from a future version
of CMake.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.{quote}
Cmake docs on the subject: https://cmake.org/cmake/help/v3.0/policy/CMP0022.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16256223#comment-16256223 ] Chris Richardson commented on QPID-7991: Just a note for posterity - the segfault under discussion did not seem to be triggered when creating the routes with the current version of qpid-route (which has recently changed to use the Broker::create API rather than the Link::Bridge approach which code comments suggest should be deprecated, see changes under https://issues.apache.org/jira/browse/QPID-7876). However it DID (prior to Alan's submitted fix) rear its ugly head when the route was created with the supposedly identical call from the c++ broker management library I authored at https://github.com/fourceu/fourc-qpid-manager and I have not yet been able to determine the exact cause. Since this fix appears to remedy the issue in either case I will abandon the investigation unless additional issues arise. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Assignee: Alan Conway >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255884#comment-16255884 ] Chris Richardson commented on QPID-7991: +1, segfault fixed! > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Assignee: Alan Conway >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7671) Problem building on debian (unstable) distribution:
[ https://issues.apache.org/jira/browse/QPID-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254481#comment-16254481 ] Chris Richardson edited comment on QPID-7671 at 11/16/17 12:23 AM: --- [~aconway] it looks like this fix got pushed to the 1.36.x branch instead of master - I suspect this was not intentional? Apologies, please disregard - I was lead astray by a pre-OS upgrade dirty build. was (Author: crichardson): [~aconway] it looks like this fix got pushed to the 1.36.x branch instead of master - I suspect this was not intentional? > Problem building on debian (unstable) distribution: > --- > > Key: QPID-7671 > URL: https://issues.apache.org/jira/browse/QPID-7671 > Project: Qpid > Issue Type: Bug > Components: C++ Build >Affects Versions: qpid-cpp-1.36.0 >Reporter: Irina Boverman >Assignee: Alan Conway > Fix For: qpid-cpp-1.37.0 > > > This does not work: > -- > cmake . -DCMAKE_BUILD_TYPE=DebWithRelInfo > make -j4 > ... > [ 34%] Linking CXX shared library libqpidcommon.so > CMakeFiles/qpidcommon.dir/qpid/log/Logger.cpp.o: In function > `boost::serialization::singleton::get_mutable_instance()': > Logger.cpp.text._ZN5boost13serialization9singletonIN4qpid3log6LoggerEE20get_mutable_instanceEv[_ZN5boost13serialization9singletonIN4qpid3log6LoggerEE20get_mutable_instanceEv]+0x5): > undefined reference to `boost::serialization::singleton_module::is_locked()' > collect2: error: ld returned 1 exit status > src/CMakeFiles/qpidcommon.dir/build.make:5583: recipe for target > 'src/libqpidcommon.so.2.0.0' failed > make[2]: *** [src/libqpidcommon.so.2.0.0] Error 1 > CMakeFiles/Makefile2:1271: recipe for target > 'src/CMakeFiles/qpidcommon.dir/all' failed > make[1]: *** [src/CMakeFiles/qpidcommon.dir/all] Error 2 > Makefile:160: recipe for target 'all' failed > make: *** [all] Error 2 > -- > In both cases: > Boost version: 1.62.0 > -- Found the following Boost libraries: > -- program_options > -- system -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (QPID-7671) Problem building on debian (unstable) distribution:
[ https://issues.apache.org/jira/browse/QPID-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7671: --- Comment: was deleted (was: [~aconway] it looks like this fix got pushed to the 1.36.x branch instead of master - I suspect this was not intentional? Apologies, please disregard - I was lead astray by a pre-OS upgrade dirty build.) > Problem building on debian (unstable) distribution: > --- > > Key: QPID-7671 > URL: https://issues.apache.org/jira/browse/QPID-7671 > Project: Qpid > Issue Type: Bug > Components: C++ Build >Affects Versions: qpid-cpp-1.36.0 >Reporter: Irina Boverman >Assignee: Alan Conway > Fix For: qpid-cpp-1.37.0 > > > This does not work: > -- > cmake . -DCMAKE_BUILD_TYPE=DebWithRelInfo > make -j4 > ... > [ 34%] Linking CXX shared library libqpidcommon.so > CMakeFiles/qpidcommon.dir/qpid/log/Logger.cpp.o: In function > `boost::serialization::singleton::get_mutable_instance()': > Logger.cpp.text._ZN5boost13serialization9singletonIN4qpid3log6LoggerEE20get_mutable_instanceEv[_ZN5boost13serialization9singletonIN4qpid3log6LoggerEE20get_mutable_instanceEv]+0x5): > undefined reference to `boost::serialization::singleton_module::is_locked()' > collect2: error: ld returned 1 exit status > src/CMakeFiles/qpidcommon.dir/build.make:5583: recipe for target > 'src/libqpidcommon.so.2.0.0' failed > make[2]: *** [src/libqpidcommon.so.2.0.0] Error 1 > CMakeFiles/Makefile2:1271: recipe for target > 'src/CMakeFiles/qpidcommon.dir/all' failed > make[1]: *** [src/CMakeFiles/qpidcommon.dir/all] Error 2 > Makefile:160: recipe for target 'all' failed > make: *** [all] Error 2 > -- > In both cases: > Boost version: 1.62.0 > -- Found the following Boost libraries: > -- program_options > -- system -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7671) Problem building on debian (unstable) distribution:
[ https://issues.apache.org/jira/browse/QPID-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254481#comment-16254481 ] Chris Richardson commented on QPID-7671: [~aconway] it looks like this fix got pushed to the 1.36.x branch instead of master - I suspect this was not intentional? > Problem building on debian (unstable) distribution: > --- > > Key: QPID-7671 > URL: https://issues.apache.org/jira/browse/QPID-7671 > Project: Qpid > Issue Type: Bug > Components: C++ Build >Affects Versions: qpid-cpp-1.36.0 >Reporter: Irina Boverman >Assignee: Alan Conway > Fix For: qpid-cpp-1.37.0 > > > This does not work: > -- > cmake . -DCMAKE_BUILD_TYPE=DebWithRelInfo > make -j4 > ... > [ 34%] Linking CXX shared library libqpidcommon.so > CMakeFiles/qpidcommon.dir/qpid/log/Logger.cpp.o: In function > `boost::serialization::singleton::get_mutable_instance()': > Logger.cpp.text._ZN5boost13serialization9singletonIN4qpid3log6LoggerEE20get_mutable_instanceEv[_ZN5boost13serialization9singletonIN4qpid3log6LoggerEE20get_mutable_instanceEv]+0x5): > undefined reference to `boost::serialization::singleton_module::is_locked()' > collect2: error: ld returned 1 exit status > src/CMakeFiles/qpidcommon.dir/build.make:5583: recipe for target > 'src/libqpidcommon.so.2.0.0' failed > make[2]: *** [src/libqpidcommon.so.2.0.0] Error 1 > CMakeFiles/Makefile2:1271: recipe for target > 'src/CMakeFiles/qpidcommon.dir/all' failed > make[1]: *** [src/CMakeFiles/qpidcommon.dir/all] Error 2 > Makefile:160: recipe for target 'all' failed > make: *** [all] Error 2 > -- > In both cases: > Boost version: 1.62.0 > -- Found the following Boost libraries: > -- program_options > -- system -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253843#comment-16253843 ] Chris Richardson edited comment on QPID-7991 at 11/15/17 5:38 PM: -- I've attached a simple program [^std_remove_if_with_smart_ptr.cpp] to show the idea behind the std::shared_ptr/std::remove_if problem. It uses a lambda rather than boost::bind but is otherwise essentially the same as the segfaulting code in qpid-cpp. Where the demo reports "Element use count: 0" the smart_ptr has been unintentionally garbage collected between the std::remove_if evaluation and later processing with the resulting iterator. was (Author: crichardson): Segfault conceptual > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Attachment: std_remove_if_with_smart_ptr.cpp Segfault conceptual > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227319#comment-16227319
]
Chris Richardson edited comment on QPID-7991 at 10/31/17 6:53 PM:
--
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
{code}
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(&Bridge::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
{code}
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the isDetached predicate is successfully executed on the Bridge
instance that subsequently transpired to be null, so presumably it was not null
at that time...
was (Author: chris.richardson):
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(&Bridge::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the invocation of the isDetached predicate is successfully executed
on the Bridge instance that subsequently transpired to be null, so presumably
it was not null at that time...
> Segfault in broker while processing active bridges
> --
>
> Key: QPID-7991
> URL: https://issues.apache.org/jira/browse/QPID-7991
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
> Environment: Ubuntu 17.10 x86_64, gcc 7.
>Reporter: Chris Richardson
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: segfault stack trace, segfault-fix.patch,
> segfault-repoduce.tar.gz
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Segfault occurs on a brackground thread within about 5-10 seconds of broker
> startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached,
> frames #3 and #5 are of particular relevance.
> The unchecked Bridge::shared_ptr derived from the iterator is null and the
> invocation of bridge->closed() triggers the segfault. Adding a simple null
> check (as per attached [^segfault-fix.patch]) fixes the segfault but not the
> underlying reason for the null pointer.
> The segfault appears to be related to how a second broker (henceforth
> "broker1") is configured; this is the one to which the links are established.
> Without broker1, the "segfaulting broker" (aka "broker2") does not do its
> thing. It may be that broker1 returns invalid data to broker2 but this is not
> in the scope of this bug report, which focuses on the segfault.
> h2. Reproduce
> Unfortunately the steps to arrive at this situation are not clear so the
> reproduce is a bit hacky - the data directory, config file and some certs for
> the two brokers are attached as a tarball in the hope that they can be
> arranged in such a way as to provide a reproduce in lieu of a purely
> step-based procedure.
> Steps to reproduce:
> * Temporarily add a DNS alias to the local machine of "octopussy" (necessary
> due to cert config and durable link config in broker2's data store)
> * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory
> (assumed to be cwd)
> * Start broker1 with "qpidd --config broker1/qpidd.conf"
> * In another shell with the same cwd, start broker2 with "qpidd --config
> broker2/qpidd.conf"
> * Observe segfault in broker2 after 5-10 seconds.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227319#comment-16227319
]
Chris Richardson commented on QPID-7991:
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(&Bridge::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the invocation of the isDetached predicate is successfully executed
on the Bridge instance that subsequently transpired to be null, so presumably
it was not null at that time...
> Segfault in broker while processing active bridges
> --
>
> Key: QPID-7991
> URL: https://issues.apache.org/jira/browse/QPID-7991
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
> Environment: Ubuntu 17.10 x86_64, gcc 7.
>Reporter: Chris Richardson
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: segfault stack trace, segfault-fix.patch,
> segfault-repoduce.tar.gz
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Segfault occurs on a brackground thread within about 5-10 seconds of broker
> startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached,
> frames #3 and #5 are of particular relevance.
> The unchecked Bridge::shared_ptr derived from the iterator is null and the
> invocation of bridge->closed() triggers the segfault. Adding a simple null
> check (as per attached [^segfault-fix.patch]) fixes the segfault but not the
> underlying reason for the null pointer.
> The segfault appears to be related to how a second broker (henceforth
> "broker1") is configured; this is the one to which the links are established.
> Without broker1, the "segfaulting broker" (aka "broker2") does not do its
> thing. It may be that broker1 returns invalid data to broker2 but this is not
> in the scope of this bug report, which focuses on the segfault.
> h2. Reproduce
> Unfortunately the steps to arrive at this situation are not clear so the
> reproduce is a bit hacky - the data directory, config file and some certs for
> the two brokers are attached as a tarball in the hope that they can be
> arranged in such a way as to provide a reproduce in lieu of a purely
> step-based procedure.
> Steps to reproduce:
> * Temporarily add a DNS alias to the local machine of "octopussy" (necessary
> due to cert config and durable link config in broker2's data store)
> * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory
> (assumed to be cwd)
> * Start broker1 with "qpidd --config broker1/qpidd.conf"
> * In another shell with the same cwd, start broker2 with "qpidd --config
> broker2/qpidd.conf"
> * Observe segfault in broker2 after 5-10 seconds.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227191#comment-16227191 ] Chris Richardson commented on QPID-7991: Tested, unfortunately no stack trace triggered by the "assert" patch. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached [^segfault-fix.patch]) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached [^segfault-fix.patch]) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached [^segfault-fix.patch]) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce
[jira] [Issue Comment Deleted] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Comment: was deleted (was: I'm incongruously logging this without the promised attachments in order to save the report in its current form. I also need to verify whether or not the bug applies to 1.36 or just master. ) > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Attachment: segfault-fix.patch > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Affects Version/s: qpid-cpp-1.36.0 > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a b
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so t
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Attachment: segfault-repoduce.tar.gz > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Unpack the attached tarball to an empty directory (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 (as daemon - we are not interested in its output at this point, available at broker1/qpidd.log if required) with "qpidd --config broker1/qpidd.conf -d" * Start the broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are at
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 (as daemon - we are not interested in its output at this point, available at broker1/qpidd.log if required) with "qpidd --config broker1/qpidd.conf -d" * Start the broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465 The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 (as daemon - we are not interested in its output at this point, available at broker1/qpidd.log if required) with "qpidd --config broker1/qpidd.conf -d" * Start the broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Un
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Attachment: segfault stack trace > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465 > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Unpack the attached tarball to an empty directory (assumed to be cwd) > * Start the broker1 (as daemon - we are not interested in its output at this > point, available at broker1/qpidd.log if required) with "qpidd --config > broker1/qpidd.conf -d" > * Start the broker2 with "qpidd --config broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221418#comment-16221418 ] Chris Richardson commented on QPID-7991: I'm incongruously logging this without the promised attachments in order to save the report in its current form. I also need to verify whether or not the bug applies to 1.36 or just master. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465 > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Unpack the attached tarball to an empty directory (assumed to be cwd) > * Start the broker1 (as daemon - we are not interested in its output at this > point, available at broker1/qpidd.log if required) with "qpidd --config > broker1/qpidd.conf -d" > * Start the broker2 with "qpidd --config broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7991) Segfault in broker while processing active bridges
Chris Richardson created QPID-7991: -- Summary: Segfault in broker while processing active bridges Key: QPID-7991 URL: https://issues.apache.org/jira/browse/QPID-7991 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-1.37.0 Environment: Ubuntu 17.10 x86_64, gcc 7. Reporter: Chris Richardson Priority: Critical Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465 The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 (as daemon - we are not interested in its output at this point, available at broker1/qpidd.log if required) with "qpidd --config broker1/qpidd.conf -d" * Start the broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
[ https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140058#comment-16140058 ] Chris Richardson commented on QPID-7894: See discussion at http://qpid.2158936.n2.nabble.com/Multiple-connections-with-ssl-client-auth-does-not-work-as-expected-td7665836.html > SSL client auth with multiple connections does not properly use ssl_cert_name > connection property > - > > Key: QPID-7894 > URL: https://issues.apache.org/jira/browse/QPID-7894 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Ubuntu >Reporter: Chris Richardson > Fix For: qpid-cpp-1.36.0 > > Attachments: qpid-multiuser-test.tar.gz > > > When 2 connections are made using ssl-client-auth within the same process > using the ssl-cert-name property to specify the user (via their cert), the > second connection uses the same cert as the first one. > This means that ACL rules will not be applied as expected. > The expected behaviour is that connections should be authorised using the > cert specified in the ssl-cert-name connection property. > The attached archive contains a script and example c++ program which set up > this scenario from scratch and demonstrate the error (NB: script recursively > deletes certain subdirectories of the current directory when run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
[ https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson closed QPID-7894. -- Resolution: Not A Bug Fix Version/s: qpid-cpp-1.36.0 Closing this issue as it appears to be related to NSS versions and not to qpid-cpp itself (nss 3.28 does not work, 3.31 works; interim versions not tested). > SSL client auth with multiple connections does not properly use ssl_cert_name > connection property > - > > Key: QPID-7894 > URL: https://issues.apache.org/jira/browse/QPID-7894 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Ubuntu >Reporter: Chris Richardson > Fix For: qpid-cpp-1.36.0 > > Attachments: qpid-multiuser-test.tar.gz > > > When 2 connections are made using ssl-client-auth within the same process > using the ssl-cert-name property to specify the user (via their cert), the > second connection uses the same cert as the first one. > This means that ACL rules will not be applied as expected. > The expected behaviour is that connections should be authorised using the > cert specified in the ssl-cert-name connection property. > The attached archive contains a script and example c++ program which set up > this scenario from scratch and demonstrate the error (NB: script recursively > deletes certain subdirectories of the current directory when run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
[ https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7894: --- Description: When 2 connections are made using ssl-client-auth within the same process using the ssl-cert-name property to specify the user (via their cert), the second connection uses the same cert as the first one. This means that ACL rules will not be applied as expected. The expected behaviour is that connections should be authorised using the cert specified in the ssl-cert-name connection property. The attached archive contains a script and example c++ program which set up this scenario from scratch and demonstrate the error (NB: script recursively deletes certain subdirectories of the current directory when run). was: When 2 connections are made using ssl-client-auth within the same process using the ssl-cert-name property to specify the user (via their cert), the second connection uses the same cert as the first one. This means that ACL rules will not be applied as expected. The expected behaviour is that connections should be authorised using the cert specified in the ssl-cert-name connection property. The attached archive contains a script and example c++ program which set up this scenario from scratch and demonstrate the error (NB: script recursively deletes certain subdirectories from wherever it is run). > SSL client auth with multiple connections does not properly use ssl_cert_name > connection property > - > > Key: QPID-7894 > URL: https://issues.apache.org/jira/browse/QPID-7894 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Ubuntu >Reporter: Chris Richardson > Attachments: qpid-multiuser-test.tar.gz > > > When 2 connections are made using ssl-client-auth within the same process > using the ssl-cert-name property to specify the user (via their cert), the > second connection uses the same cert as the first one. > This means that ACL rules will not be applied as expected. > The expected behaviour is that connections should be authorised using the > cert specified in the ssl-cert-name connection property. > The attached archive contains a script and example c++ program which set up > this scenario from scratch and demonstrate the error (NB: script recursively > deletes certain subdirectories of the current directory when run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
[ https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7894: --- Description: When 2 connections are made using ssl-client-auth within the same process using the ssl-cert-name property to specify the user (via their cert), the second connection uses the same cert as the first one. This means that ACL rules will not be applied as expected. The expected behaviour is that connections should be authorised using the cert specified in the ssl-cert-name connection property. The attached archive contains a script and example c++ program which set up this scenario from scratch and demonstrate the error (NB: script recursively deletes certain subdirectories from wherever it is run). was: When 2 connections are made using ssl-client-auth within the same process using the ssl-cert-name property to specify the user (via their cert), the second connection uses the same cert as the first one. This means that ACL rules will not be applied as expected. The expected behaviour is that connections should be authorised using the cert specified in the ssl-cert-name connection property. The attached archive contains a script and demo c++ program which set up this scenario from scratch and demonstrate the error (NB: script recursively deletes certain subdirectories from wherever it is run). > SSL client auth with multiple connections does not properly use ssl_cert_name > connection property > - > > Key: QPID-7894 > URL: https://issues.apache.org/jira/browse/QPID-7894 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Ubuntu >Reporter: Chris Richardson > Attachments: qpid-multiuser-test.tar.gz > > > When 2 connections are made using ssl-client-auth within the same process > using the ssl-cert-name property to specify the user (via their cert), the > second connection uses the same cert as the first one. > This means that ACL rules will not be applied as expected. > The expected behaviour is that connections should be authorised using the > cert specified in the ssl-cert-name connection property. > The attached archive contains a script and example c++ program which set up > this scenario from scratch and demonstrate the error (NB: script recursively > deletes certain subdirectories from wherever it is run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
[ https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16135781#comment-16135781 ] Chris Richardson edited comment on QPID-7894 at 8/21/17 8:40 PM: - Attached archive with scripts and example program which set up and demonstrate issue was (Author: chris.richardson): Scripts and example program which set up and demonstrate issue > SSL client auth with multiple connections does not properly use ssl_cert_name > connection property > - > > Key: QPID-7894 > URL: https://issues.apache.org/jira/browse/QPID-7894 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Ubuntu >Reporter: Chris Richardson > Attachments: qpid-multiuser-test.tar.gz > > > When 2 connections are made using ssl-client-auth within the same process > using the ssl-cert-name property to specify the user (via their cert), the > second connection uses the same cert as the first one. > This means that ACL rules will not be applied as expected. > The expected behaviour is that connections should be authorised using the > cert specified in the ssl-cert-name connection property. > The attached archive contains a script and demo c++ program which set up this > scenario from scratch and demonstrate the error (NB: script recursively > deletes certain subdirectories from wherever it is run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
[ https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7894: --- Attachment: qpid-multiuser-test.tar.gz Scripts and example program which set up and demonstrate issue > SSL client auth with multiple connections does not properly use ssl_cert_name > connection property > - > > Key: QPID-7894 > URL: https://issues.apache.org/jira/browse/QPID-7894 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Ubuntu >Reporter: Chris Richardson > Attachments: qpid-multiuser-test.tar.gz > > > When 2 connections are made using ssl-client-auth within the same process > using the ssl-cert-name property to specify the user (via their cert), the > second connection uses the same cert as the first one. > This means that ACL rules will not be applied as expected. > The expected behaviour is that connections should be authorised using the > cert specified in the ssl-cert-name connection property. > The attached archive contains a script and demo c++ program which set up this > scenario from scratch and demonstrate the error (NB: script recursively > deletes certain subdirectories from wherever it is run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7894) SSL client auth with multiple connections does not properly use ssl_cert_name connection property
Chris Richardson created QPID-7894: -- Summary: SSL client auth with multiple connections does not properly use ssl_cert_name connection property Key: QPID-7894 URL: https://issues.apache.org/jira/browse/QPID-7894 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-1.36.0 Environment: Ubuntu Reporter: Chris Richardson When 2 connections are made using ssl-client-auth within the same process using the ssl-cert-name property to specify the user (via their cert), the second connection uses the same cert as the first one. This means that ACL rules will not be applied as expected. The expected behaviour is that connections should be authorised using the cert specified in the ssl-cert-name connection property. The attached archive contains a script and demo c++ program which set up this scenario from scratch and demonstrate the error (NB: script recursively deletes certain subdirectories from wherever it is run). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114432#comment-16114432 ] Chris Richardson commented on QPID-7876: [~gsim], I think I've got it right now - apologies for the messy approach! I had a look at extending the tests in federation.py to better test the RouteManager class but I'm afraid I baulked at the CTest/python/valgrind world I found myself in; the attached bash script may have to suffice for now. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Attachments: test-routes.sh > > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114422#comment-16114422 ] Chris Richardson edited comment on QPID-7876 at 8/4/17 2:14 PM: The attached [^test-routes.sh] demonstrates some of the issues with bridge matching and also verifies some other potential errors have not snuck in uninvited! Run from root of source dir. was (Author: chris.richardson): This test script demonstrates some of the issues with bridge matching and also verifies some other potential errors have not snuck in uninvited! Run from root of source dir. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Attachments: test-routes.sh > > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114422#comment-16114422 ] Chris Richardson edited comment on QPID-7876 at 8/4/17 2:14 PM: The attached [^test-routes.sh] demonstrates some of the issues with bridge matching and also verifies that some other potential errors have not snuck in uninvited! Run from root of source dir. was (Author: chris.richardson): The attached [^test-routes.sh] demonstrates some of the issues with bridge matching and also verifies some other potential errors have not snuck in uninvited! Run from root of source dir. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Attachments: test-routes.sh > > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7876: --- Attachment: test-routes.sh This test script demonstrates some of the issues with bridge matching and also verifies some other potential errors have not snuck in uninvited! Run from root of source dir. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Attachments: test-routes.sh > > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson reopened QPID-7876: Re-opening due to a couple of oversights in the submitted patch. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112518#comment-16112518 ] Chris Richardson commented on QPID-7876: Damn, I didn't use link name . I'll update the PR. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112508#comment-16112508
]
Chris Richardson commented on QPID-7876:
[~gsim] Did you notice my comment in the PR about bridge naming? As stated I
wasn't sure how to construct a unique name so I basically made something
up. It just so happened that it independently almost matched the implementation
in Broker::createName.
Considerations were:
* the name can't start with QPID_NAME_PREFIX ("qpid.") (enforced by broker)
* Uniqueness should probably be consistent with the route matching pattern
(link, src, dest, key, src_local). This is not the case in Broker::createName
which does not use src_local. However I don't think that that implementation is
used any more (kind != ENCODED_IDENTIFIER_V1)...
> qpid-route does not properly consider src-local when matching bridges
> -
>
> Key: QPID-7876
> URL: https://issues.apache.org/jira/browse/QPID-7876
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Chris Richardson
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> qpid-route does not properly consider src-local when matching bridges. The
> practical upshot of this is that it may consider routes to be duplicates when
> they are in fact not.
> Take the following (slightly contrived) scenario:
> Brokers A and B both have queues named "test.queue" and default exchanges
> named "amq.direct".
> We would like a queue route to pull messages from B:test.queue to
> A:amq.direct and a src_local route to push messages from A:test.queue to
> B:amq.direct. Since qpid-route does not consider the src-local flag, it will
> regard the second route to be a duplicate and will not allow it to be added.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7874) qpid-route performs an unnecessary link check when adding routes
[
https://issues.apache.org/jira/browse/QPID-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111698#comment-16111698
]
Chris Richardson commented on QPID-7874:
While testing an alternative patch along the lines above, I noticed that the
"checkLink" method does not (as I originally thought) fail the operation if the
link does not become active - only if it is not created at all or is in an
error state (which does NOT include being in a disconnected state).
Example output from the existing qpid-route (with a broker on port 5672 and
nothing on 5674):
{quote}
$ qpid-route -v route add localhost:5672 localhost:5674 amq.direct key
Link state is Waiting
Creating inter-broker binding...
Bridge method returned: 0 OK
$ qpid-route link list
HostPortTransport Durable State Last Error
=
localhost 5674tcp N Waiting Connection refused
{quote}
Nevertheless I'll submit the now-rather-trivial PR (the effect of which is to
avoid the extra fetches of the link and 3 second wait for the link to come up)
and see what you think...
> qpid-route performs an unnecessary link check when adding routes
>
>
> Key: QPID-7874
> URL: https://issues.apache.org/jira/browse/QPID-7874
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Chris Richardson
>
> Having connected to the destination broker (for "normal" routes) or source
> broker (for "src-local" routes), the qpid-route utility checks that the
> inter-broker link is active before configuring the new bridge. This check is
> not necessary since the bridge can still be created even if the network link
> is down. When the remote broker becomes accessible, the inter-broker link and
> the bridge will come up as expected.
> PR: https://github.com/apache/qpid-cpp/pull/5
> An alternative to simply removing the check might be to make it a
> configuration option.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7874) qpid-route performs an unnecessary link check when adding routes
[ https://issues.apache.org/jira/browse/QPID-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111644#comment-16111644 ] Chris Richardson commented on QPID-7874: That sounds like a good solution. I certainly agree there are cases where immediate feedback about a link failure would be relevant, eg: perhaps the most common usage, when manually entering a broker URL. > qpid-route performs an unnecessary link check when adding routes > > > Key: QPID-7874 > URL: https://issues.apache.org/jira/browse/QPID-7874 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > > Having connected to the destination broker (for "normal" routes) or source > broker (for "src-local" routes), the qpid-route utility checks that the > inter-broker link is active before configuring the new bridge. This check is > not necessary since the bridge can still be created even if the network link > is down. When the remote broker becomes accessible, the inter-broker link and > the bridge will come up as expected. > PR: https://github.com/apache/qpid-cpp/pull/5 > An alternative to simply removing the check might be to make it a > configuration option. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7876: --- Remaining Estimate: 4h (was: 4m) Original Estimate: 4h (was: 4m) > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Original Estimate: 4h > Remaining Estimate: 4h > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
[ https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109647#comment-16109647 ] Chris Richardson commented on QPID-7876: Having modified qpid-route to include src-local in bridge matching, I found that the broker itself (silently) does not accept the new bridge for the same reason. On examining src/qpid/broker/Link.cpp I found the following comment (line 721): /* TBD: deprecate this interface in favor(sic) of the Broker::create() method. The * Broker::create() method allows the user to assign a name to the bridge. */ I am therefore creating a PR in which qpid-route uses the Broker::create() method. This seemed like a better option than modifying the broker code, which is to be deprecated anyway. > qpid-route does not properly consider src-local when matching bridges > - > > Key: QPID-7876 > URL: https://issues.apache.org/jira/browse/QPID-7876 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Original Estimate: 4m > Remaining Estimate: 4m > > qpid-route does not properly consider src-local when matching bridges. The > practical upshot of this is that it may consider routes to be duplicates when > they are in fact not. > Take the following (slightly contrived) scenario: > Brokers A and B both have queues named "test.queue" and default exchanges > named "amq.direct". > We would like a queue route to pull messages from B:test.queue to > A:amq.direct and a src_local route to push messages from A:test.queue to > B:amq.direct. Since qpid-route does not consider the src-local flag, it will > regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7876) qpid-route does not properly consider src-local when matching bridges
Chris Richardson created QPID-7876: -- Summary: qpid-route does not properly consider src-local when matching bridges Key: QPID-7876 URL: https://issues.apache.org/jira/browse/QPID-7876 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-1.36.0 Reporter: Chris Richardson qpid-route does not properly consider src-local when matching bridges. The practical upshot of this is that it may consider routes to be duplicates when they are in fact not. Take the following (slightly contrived) scenario: Brokers A and B both have queues named "test.queue" and default exchanges named "amq.direct". We would like a queue route to pull messages from B:test.queue to A:amq.direct and a src_local route to push messages from A:test.queue to B:amq.direct. Since qpid-route does not consider the src-local flag, it will regard the second route to be a duplicate and will not allow it to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7875) qpid-route fetches links multiple times when deleting routes
[ https://issues.apache.org/jira/browse/QPID-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7875: --- Description: When deleting routes/queue routes, qpid-route first retrieves the inter-broker link on which the route is to be deleted, then (having deleted the bridge and only if configured to delete the link) gets the same link again in order to close it. This results in an extra RPC call which unnecessarily reads all links from the broker a second time. PR: https://github.com/apache/qpid-cpp/pull/6 was: When deleting routes/queue routes, qpid-route first retrieves the inter-broker link on which the route is to be deleted, then (having deleted the bridge and only if configured to delete the link) gets the same link again in order to close it. This results in an extra RPC call which unnecessarily reads all links from the broker a second time. PR: > qpid-route fetches links multiple times when deleting routes > > > Key: QPID-7875 > URL: https://issues.apache.org/jira/browse/QPID-7875 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > > When deleting routes/queue routes, qpid-route first retrieves the > inter-broker link on which the route is to be deleted, then (having deleted > the bridge and only if configured to delete the link) gets the same link > again in order to close it. This results in an extra RPC call which > unnecessarily reads all links from the broker a second time. > PR: https://github.com/apache/qpid-cpp/pull/6 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7875) qpid-route fetches links multiple times when deleting routes
[ https://issues.apache.org/jira/browse/QPID-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7875: --- Summary: qpid-route fetches links multiple times when deleting routes (was: qpid-route fetches link multiple times when deleting routes) > qpid-route fetches links multiple times when deleting routes > > > Key: QPID-7875 > URL: https://issues.apache.org/jira/browse/QPID-7875 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > > When deleting routes/queue routes, qpid-route first retrieves the > inter-broker link on which the route is to be deleted, then (having deleted > the bridge and only if configured to delete the link) gets the same link > again in order to close it. This results in an extra RPC call which > unnecessarily reads all links from the broker a second time. > PR: -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7875) qpid-route fetches link multiple times when deleting routes
Chris Richardson created QPID-7875: -- Summary: qpid-route fetches link multiple times when deleting routes Key: QPID-7875 URL: https://issues.apache.org/jira/browse/QPID-7875 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: qpid-cpp-1.36.0 Reporter: Chris Richardson When deleting routes/queue routes, qpid-route first retrieves the inter-broker link on which the route is to be deleted, then (having deleted the bridge and only if configured to delete the link) gets the same link again in order to close it. This results in an extra RPC call which unnecessarily reads all links from the broker a second time. PR: -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7874) qpid-route performs an unnecessary link check when adding routes
[ https://issues.apache.org/jira/browse/QPID-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7874: --- Description: Having connected to the destination broker (for "normal" routes) or source broker (for "src-local" routes), the qpid-route utility checks that the inter-broker link is active before configuring the new bridge. This check is not necessary since the bridge can still be created even if the network link is down. When the remote broker becomes accessible, the inter-broker link and the bridge will come up as expected. PR: https://github.com/apache/qpid-cpp/pull/5 An alternative to simply removing the check might be to make it a configuration option. was: Having connected to the destination broker (for "normal" routes) or source broker (for "src-local" routes), the qpid-route utility checks that the inter-broker link is active before configuring the new bridge. This check is not necessary since the bridge can still be created even if the network link is down. When the remote broker becomes accessible, the inter-broker link and the bridge will come up as expected. PR: An alternative to simply removing the check might be to make it a configuration option. > qpid-route performs an unnecessary link check when adding routes > > > Key: QPID-7874 > URL: https://issues.apache.org/jira/browse/QPID-7874 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > > Having connected to the destination broker (for "normal" routes) or source > broker (for "src-local" routes), the qpid-route utility checks that the > inter-broker link is active before configuring the new bridge. This check is > not necessary since the bridge can still be created even if the network link > is down. When the remote broker becomes accessible, the inter-broker link and > the bridge will come up as expected. > PR: https://github.com/apache/qpid-cpp/pull/5 > An alternative to simply removing the check might be to make it a > configuration option. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7874) qpid-route performs an unnecessary link check when adding routes
Chris Richardson created QPID-7874: -- Summary: qpid-route performs an unnecessary link check when adding routes Key: QPID-7874 URL: https://issues.apache.org/jira/browse/QPID-7874 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: qpid-cpp-1.36.0 Reporter: Chris Richardson Having connected to the destination broker (for "normal" routes) or source broker (for "src-local" routes), the qpid-route utility checks that the inter-broker link is active before configuring the new bridge. This check is not necessary since the bridge can still be created even if the network link is down. When the remote broker becomes accessible, the inter-broker link and the bridge will come up as expected. PR: An alternative to simply removing the check might be to make it a configuration option. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7863) qpidd-1.36 init script fails with "source: not found" on ubuntu
Chris Richardson created QPID-7863: -- Summary: qpidd-1.36 init script fails with "source: not found" on ubuntu Key: QPID-7863 URL: https://issues.apache.org/jira/browse/QPID-7863 Project: Qpid Issue Type: Bug Components: Packaging Affects Versions: qpid-cpp-1.36.0 Environment: Travis (Ubuntu Trusty) Reporter: Chris Richardson While trying to install qpidd on Travis (Ubuntu Trusty) from the qpid/testing ppa I'm getting the error /etc/init.d/qpidd: 52: /etc/init.d/qpidd: source: not found see https://travis-ci.org/fourceu/fourc-qpid-manager/jobs/254889450 line 660. I think this is because the init script is not compatible with Ubuntu (even if the offending line were changed to use "." instead of "source", the requested functions script would not exist). Could we please have an updated deb package with an Ubuntu init script? :) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7714) Suppress auto_ptr warnings
[ https://issues.apache.org/jira/browse/QPID-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936365#comment-15936365 ] Chris Richardson commented on QPID-7714: [~jr...@redhat.com] Can you please check your conclusion regarding the SYSTEM keyword and portability? My understanding is that the SYSTEM keyword should be perfectly portable - perhaps the unrelated "gnu++03" compiler directive you added in the same commit (https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=2ee9f79) is actually the portability culprit? My patch for the SYSTEM keyword has nothing to do with the auto_ptr deprecation warnings (I've tested this and get the same 2500 warnings); could we have it reinstated in the 1.37 release? > Suppress auto_ptr warnings > -- > > Key: QPID-7714 > URL: https://issues.apache.org/jira/browse/QPID-7714 > Project: Qpid > Issue Type: Improvement > Components: C++ Build >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: qpid-cpp-1.37.0 > > > Now that some compilers have made C++11 their default, our use of auto_ptr is > producing too many warnings. There's a fix in place for this, but it may > affect portability, so we will use another approach. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930889#comment-15930889 ] Chris Richardson edited comment on QPID-7630 at 3/17/17 11:35 PM: -- As a QA -nazi- enthusiast I would be all in favour of a solution where warnings are always shown but the -Werror switch can be turned off. My proposition to have both was simply to avoid removing existing functionality. In the case of Gentoo (which is my focus), the nature of the distro ^1^ makes displaying warnings a key part of diagnosing everyday installation problems. ^1^ packes installed by building from source, bleeding-edge versions of all packages, often highly customised and optimised build environment was (Author: crichardson): As a QA -nazi- enthusiast I would be all in favour of a solution where warnings are always shown but the -Werror switch can be turned off. My proposition to have both was simply to avoid removing existing functionality. In the case of Gentoo (which is my focus), the nature of the distro ^1^ makes displaying warnings a key part of diagnosing everyday installation problems. ^1^ packes installed by building from source, bleeding-edge versions of all packages, highly customisable and optimised build environment > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: GNU compilers >Reporter: Chris Richardson >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.38.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to be > able to disable warnings as errors in the build. This is the recommendation > for instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930889#comment-15930889 ] Chris Richardson edited comment on QPID-7630 at 3/17/17 11:34 PM: -- As a QA -nazi- enthusiast I would be all in favour of a solution where warnings are always shown but the -Werror switch can be turned off. My proposition to have both was simply to avoid removing existing functionality. In the case of Gentoo (which is my focus), the nature of the distro ^1^ makes displaying warnings a key part of diagnosing everyday installation problems. ^1^ packes installed by building from source, bleeding-edge versions of all packages, highly customisable and optimised build environment was (Author: crichardson): As a QA -nazi- enthusiast I would be all in favour of a solution where warnings are always shown but the -Werror switch can be turned off. My proposition to have both was simply to avoid removing existing functionality. In the case of Gentoo (which is my focus), the nature of the distro ^1^ makes displaying warnings a key part of diagnosing everyday installation problems. ^1^ bleeding-edge versions of all packages, highly customisable and optimised build environment > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: GNU compilers >Reporter: Chris Richardson >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.38.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to be > able to disable warnings as errors in the build. This is the recommendation > for instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930889#comment-15930889 ] Chris Richardson commented on QPID-7630: As a QA -nazi- enthusiast I would be all in favour of a solution where warnings are always shown but the -Werror switch can be turned off. My proposition to have both was simply to avoid removing existing functionality. In the case of Gentoo (which is my focus), the nature of the distro ^1^ makes displaying warnings a key part of diagnosing everyday installation problems. ^1^ bleeding-edge versions of all packages, highly customisable and optimised build environment > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: GNU compilers >Reporter: Chris Richardson >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.38.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to be > able to disable warnings as errors in the build. This is the recommendation > for instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7630: --- Description: It could be useful in some situations (eg: when packaging/installing) to be able to disable warnings as errors in the build. This is the recommendation for instance of the Gentoo packaging guide (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section "-Werror compiler flag not removed"). See attached patch. was: It could be useful in some situations (eg: when packaging/installing) to disable warnings as errors in the build. This is the recommendation for instance of the Gentoo packaging guide (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section "-Werror compiler flag not removed"). See attached patch. > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 > Environment: GNU compilers >Reporter: Chris Richardson > Fix For: qpid-cpp-1.37.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to be > able to disable warnings as errors in the build. This is the recommendation > for instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7630: --- Attachment: 1.36.0-disable-warnings-as-errors-switch.patch > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 > Environment: GNU compilers >Reporter: Chris Richardson > Fix For: qpid-cpp-1.37.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to > disable warnings as errors in the build. This is the recommendation for > instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
Chris Richardson created QPID-7630: -- Summary: Add a CMake switch to allow -Werror to be switched off Key: QPID-7630 URL: https://issues.apache.org/jira/browse/QPID-7630 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: qpid-cpp-1.36.0 Environment: GNU compilers Reporter: Chris Richardson Fix For: qpid-cpp-1.37.0 It could be useful in some situations (eg: when packaging/installing) to disable warnings as errors in the build. This is the recommendation for instance of the Gentoo packaging guide (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section "-Werror compiler flag not removed"). See attached patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7629) Use CMake "SYSTEM" keyword when including headers
Chris Richardson created QPID-7629: -- Summary: Use CMake "SYSTEM" keyword when including headers Key: QPID-7629 URL: https://issues.apache.org/jira/browse/QPID-7629 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: qpid-cpp-1.36.0 Reporter: Chris Richardson Priority: Critical Fix For: qpid-cpp-1.37.0 This change would prevent -Werror being applied to code in header files included from dependent libraries, which can cause failures such as: [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o In file included from /usr/include/nss/ssl.h:18:0, from /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list [-Werror=pedantic] ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, ^ cc1plus: all warnings being treated as errors -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7629) Use CMake "SYSTEM" keyword when including headers
[ https://issues.apache.org/jira/browse/QPID-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7629: --- Description: See attached patch which applies this change to the NSS and SASL include directories. The patch does not affect the included headers from perl, python, ruby, boost or qpid-proton since it is probably not necessary to consider those dependencies. This change would prevent -Werror being applied to code in header files included from dependent libraries, which can cause failures such as: [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o In file included from /usr/include/nss/ssl.h:18:0, from /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list [-Werror=pedantic] ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, ^ cc1plus: all warnings being treated as errors was: See attached patch which applies this change to the NSS and SASL include directories. The patch does not affect the included headers from perl, python, ruby or boost since it is probably not necessary to consider those dependencies. This change would prevent -Werror being applied to code in header files included from dependent libraries, which can cause failures such as: [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o In file included from /usr/include/nss/ssl.h:18:0, from /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list [-Werror=pedantic] ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, ^ cc1plus: all warnings being treated as errors > Use CMake "SYSTEM" keyword when including headers > - > > Key: QPID-7629 > URL: https://issues.apache.org/jira/browse/QPID-7629 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Fix For: qpid-cpp-1.37.0 > > Attachments: 1.36.0-system-includes.patch > > > See attached patch which applies this change to the NSS and SASL include > directories. The patch does not affect the included headers from perl, > python, ruby, boost or qpid-proton since it is probably not necessary to > consider those dependencies. > This change would prevent -Werror being applied to code in header files > included from dependent libraries, which can cause failures such as: > [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o > In file included from /usr/include/nss/ssl.h:18:0, > from > /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: > /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list > [-Werror=pedantic] > ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, > ^ > cc1plus: all warnings being treated as errors -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7629) Use CMake "SYSTEM" keyword when including headers
[ https://issues.apache.org/jira/browse/QPID-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7629: --- Description: See attached patch which applies this change to the NSS and SASL include directories. The patch does not affect the included headers from perl, python, ruby or boost since it is probably not necessary to consider those dependencies. This change would prevent -Werror being applied to code in header files included from dependent libraries, which can cause failures such as: [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o In file included from /usr/include/nss/ssl.h:18:0, from /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list [-Werror=pedantic] ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, ^ cc1plus: all warnings being treated as errors was: This change would prevent -Werror being applied to code in header files included from dependent libraries, which can cause failures such as: [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o In file included from /usr/include/nss/ssl.h:18:0, from /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list [-Werror=pedantic] ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, ^ cc1plus: all warnings being treated as errors > Use CMake "SYSTEM" keyword when including headers > - > > Key: QPID-7629 > URL: https://issues.apache.org/jira/browse/QPID-7629 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Fix For: qpid-cpp-1.37.0 > > Attachments: 1.36.0-system-includes.patch > > > See attached patch which applies this change to the NSS and SASL include > directories. The patch does not affect the included headers from perl, > python, ruby or boost since it is probably not necessary to consider those > dependencies. > This change would prevent -Werror being applied to code in header files > included from dependent libraries, which can cause failures such as: > [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o > In file included from /usr/include/nss/ssl.h:18:0, > from > /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: > /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list > [-Werror=pedantic] > ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, > ^ > cc1plus: all warnings being treated as errors -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7629) Use CMake "SYSTEM" keyword when including headers
[ https://issues.apache.org/jira/browse/QPID-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7629: --- Attachment: 1.36.0-system-includes.patch > Use CMake "SYSTEM" keyword when including headers > - > > Key: QPID-7629 > URL: https://issues.apache.org/jira/browse/QPID-7629 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Fix For: qpid-cpp-1.37.0 > > Attachments: 1.36.0-system-includes.patch > > > This change would prevent -Werror being applied to code in header files > included from dependent libraries, which can cause failures such as: > [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o > In file included from /usr/include/nss/ssl.h:18:0, > from > /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: > /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list > [-Werror=pedantic] > ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, > ^ > cc1plus: all warnings being treated as errors -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7629) Use CMake "SYSTEM" keyword when including headers
[ https://issues.apache.org/jira/browse/QPID-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7629: --- Priority: Major (was: Critical) > Use CMake "SYSTEM" keyword when including headers > - > > Key: QPID-7629 > URL: https://issues.apache.org/jira/browse/QPID-7629 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 >Reporter: Chris Richardson > Fix For: qpid-cpp-1.37.0 > > > This change would prevent -Werror being applied to code in header files > included from dependent libraries, which can cause failures such as: > [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o > In file included from /usr/include/nss/ssl.h:18:0, > from > /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30: > /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list > [-Werror=pedantic] > ssl_sig_rsa_pkcs1_sha1md5 = 0x10101, > ^ > cc1plus: all warnings being treated as errors -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058568#comment-15058568
]
Chris Richardson commented on QPIDJMS-141:
--
Ah OK. Thanks for the explanation.
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058516#comment-15058516
]
Chris Richardson commented on QPIDJMS-141:
--
That's very specific! I might possibly be doing exactly that...
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
> Fix For: 0.7.0
>
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-141) Thread sync error can cause long blocking delay after message send
Chris Richardson created QPIDJMS-141:
Summary: Thread sync error can cause long blocking delay after
message send
Key: QPIDJMS-141
URL: https://issues.apache.org/jira/browse/QPIDJMS-141
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.6.0
Reporter: Chris Richardson
Fix For: 0.7.0
There is a discontinuity in the thread synchronisation between the
JmsConnection and AmqpProvider classes when sending a message: the
JmsConnection class awaits a signal after requesting message transmission (line
615, "request.sync();") while the AmqpProvider does not send the expected
signal (lines 486/487,
if (couldSend && envelope.isSendAsync()) {
request.onSuccess();
)
This results in a ~1000ms blocking delay while the request.sync() times out.
This only happens in a scenario where the JmsSession determines that the
message should be sent synchronously (lines 668/669:
boolean sync = connection.isAlwaysSyncSend() ||
(!connection.isForceAsyncSend() && deliveryMode ==
DeliveryMode.PERSISTENT && !getTransacted());
).
One workaround for this is to set the MessageProducer deliveryMode to
DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
operation to be asynchronous and so the AmqpProvider signals the request as
expected by the JmsConnection. However this may have other side-effects...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDJMS-140) JmsMessage.copy method incorrectly assigns readOnlyBody to readOnlyProperties
[
https://issues.apache.org/jira/browse/QPIDJMS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson closed QPIDJMS-140.
3 hour response time - not bad! ;)
> JmsMessage.copy method incorrectly assigns readOnlyBody to readOnlyProperties
> -
>
> Key: QPIDJMS-140
> URL: https://issues.apache.org/jira/browse/QPIDJMS-140
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
>Assignee: Timothy Bish
> Fix For: 0.7.0
>
>
> Error on line 60 of JmsMessage.java:
> protected void copy(JmsMessage other) {
> this.readOnlyBody = other.readOnlyBody;
> this.readOnlyProperties = other.readOnlyBody;
> should be
> this.readOnlyProperties = other.readOnlyProperties;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-140) JmsMessage.copy method incorrectly assigns readOnlyBody to readOnlyProperties
[
https://issues.apache.org/jira/browse/QPIDJMS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated QPIDJMS-140:
-
Summary: JmsMessage.copy method incorrectly assigns readOnlyBody to
readOnlyProperties (was: Copy method incorrectly assigns readOnlyBody to
readOnlyProperties)
> JmsMessage.copy method incorrectly assigns readOnlyBody to readOnlyProperties
> -
>
> Key: QPIDJMS-140
> URL: https://issues.apache.org/jira/browse/QPIDJMS-140
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
> Fix For: 0.7.0
>
>
> Error on line 60 of JmsMessage.java:
> protected void copy(JmsMessage other) {
> this.readOnlyBody = other.readOnlyBody;
> this.readOnlyProperties = other.readOnlyBody;
> should be
> this.readOnlyProperties = other.readOnlyProperties;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-140) Copy method incorrectly assigns readOnlyBody to readOnlyProperties
Chris Richardson created QPIDJMS-140:
Summary: Copy method incorrectly assigns readOnlyBody to
readOnlyProperties
Key: QPIDJMS-140
URL: https://issues.apache.org/jira/browse/QPIDJMS-140
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.6.0
Reporter: Chris Richardson
Fix For: 0.7.0
Error on line 60 of JmsMessage.java:
protected void copy(JmsMessage other) {
this.readOnlyBody = other.readOnlyBody;
this.readOnlyProperties = other.readOnlyBody;
should be
this.readOnlyProperties = other.readOnlyProperties;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6821) Python tools scripts should specify correct python version in shebang
[ https://issues.apache.org/jira/browse/QPID-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-6821: --- Description: In systems with both python2 and python3 installed, with python3 as the default, qpid-tools scripts (qpid-stat, qpid-config etc) fail due to being executed with the unsupported python3 VM. If the scripts require python2, should they not specify this in their shebangs, eg: #!/bin/env python2.7 rather than #!/bin/env python ? was: In systems with both python2 and python3 installed, with python3 as the default, qpid-tools scripts (qpid-stat, qpid-config etc) fail due to being executed with the unsupported python3 VM. If the scripts require python2, should they not specify this in their shebangs, eg: #!/bin/env python2 rather than #!/bin/env python ? > Python tools scripts should specify correct python version in shebang > - > > Key: QPID-6821 > URL: https://issues.apache.org/jira/browse/QPID-6821 > Project: Qpid > Issue Type: Bug > Components: Python Tools >Affects Versions: 0.32 > Environment: Linux, python 2.7 and python 3.4 >Reporter: Chris Richardson > Fix For: qpid-tools-next > > > In systems with both python2 and python3 installed, with python3 as the > default, qpid-tools scripts (qpid-stat, qpid-config etc) fail due to being > executed with the unsupported python3 VM. If the scripts require python2, > should they not specify this in their shebangs, eg: > #!/bin/env python2.7 > rather than > #!/bin/env python > ? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-6821) Python tools scripts should specify correct python version in shebang
Chris Richardson created QPID-6821: -- Summary: Python tools scripts should specify correct python version in shebang Key: QPID-6821 URL: https://issues.apache.org/jira/browse/QPID-6821 Project: Qpid Issue Type: Bug Components: Python Tools Affects Versions: 0.32 Environment: Linux, python 2.7 and python 3.4 Reporter: Chris Richardson Fix For: qpid-tools-next In systems with both python2 and python3 installed, with python3 as the default, qpid-tools scripts (qpid-stat, qpid-config etc) fail due to being executed with the unsupported python3 VM. If the scripts require python2, should they not specify this in their shebangs, eg: #!/bin/env python2 rather than #!/bin/env python ? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5927) Broker does not support whitespace in passwords in SSL password file
[ https://issues.apache.org/jira/browse/QPID-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-5927: --- Affects Version/s: 0.30 > Broker does not support whitespace in passwords in SSL password file > > > Key: QPID-5927 > URL: https://issues.apache.org/jira/browse/QPID-5927 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28, 0.30 >Reporter: Chris Richardson > > qpid/sys/ssl/util.cpp reads passwords from the password file with > ... > std::string password; > file >> password; > ... > The stream operator stops reading at the first whitespace character so a > password of eg: "this is a password" (considered valid by certutil) will not > be properly parsed by the broker. > Possibly use std::getline(file, password); or a stream manipulator instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5927) Broker does not support whitespace in passwords in SSL password file
[ https://issues.apache.org/jira/browse/QPID-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-5927: --- Description: qpid/sys/ssl/util.cpp reads passwords from the password file with ... std::string password; file >> password; ... The stream operator stops reading at the first whitespace character so a password of eg: "this is a password" (considered valid by certutil) will not be properly parsed by the broker. Possibly use std::getline(file, password); or a stream manipulator instead. was: qpid/sys/ssl/util.cpp reads passwords from the password file with ... std::string password; file >> password; ... The stream operator stops reading at the first whitespace character so a password of eg: "this is a password" (considered valid by certutil) will not be properly parsed by the broker. Possibly use std::getline(file, password); or a manipulator instead. > Broker does not support whitespace in passwords in SSL password file > > > Key: QPID-5927 > URL: https://issues.apache.org/jira/browse/QPID-5927 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Chris Richardson > > qpid/sys/ssl/util.cpp reads passwords from the password file with > ... > std::string password; > file >> password; > ... > The stream operator stops reading at the first whitespace character so a > password of eg: "this is a password" (considered valid by certutil) will not > be properly parsed by the broker. > Possibly use std::getline(file, password); or a stream manipulator instead. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5927) Broker does not support whitespace in passwords in SSL password file
Chris Richardson created QPID-5927: -- Summary: Broker does not support whitespace in passwords in SSL password file Key: QPID-5927 URL: https://issues.apache.org/jira/browse/QPID-5927 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.28 Reporter: Chris Richardson qpid/sys/ssl/util.cpp reads passwords from the password file with ... std::string password; file >> password; ... The stream operator stops reading at the first whitespace character so a password of eg: "this is a password" (considered valid by certutil) will not be properly parsed by the broker. Possibly use std::getline(file, password); or a manipulator instead. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-5899) Documentation states incorrect connection option for SSL
[ https://issues.apache.org/jira/browse/QPID-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066310#comment-14066310 ] Chris Richardson edited comment on QPID-5899 at 7/18/14 12:52 PM: -- There is some confusion here (mostly on my part): the property on the qpid::client::ConnectionSettings class is "protocol", but the protocol option which can be passed to the qpid::messaging::Connection class as a string is "transport", while "protocol" refers to the AMQP protocol version. was (Author: chris.richardson): There is be some confusion here (on my part): the property on the qpid::client::ConnectionSettings class is "protocol", but the protocol option which can be passed to the qpid::messaging::Connection class as a string is "transport", while "protocol" refers to the AMQP protocol version. > Documentation states incorrect connection option for SSL > > > Key: QPID-5899 > URL: https://issues.apache.org/jira/browse/QPID-5899 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Chris Richardson >Priority: Minor > > The documentation for setting up SSL at > http://qpid.apache.org/releases/qpid-0.28/cpp-broker/book/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL > states: > "To open an SSL enabled connection in the Qpid Messaging API, set the > protocol connection option to ssl." > The correct connection option is "transport", not "protocol". -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5899) Documentation states incorrect connection option for SSL
[ https://issues.apache.org/jira/browse/QPID-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066310#comment-14066310 ] Chris Richardson commented on QPID-5899: There is be some confusion here (on my part): the property on the qpid::client::ConnectionSettings class is "protocol", but the protocol option which can be passed to the qpid::messaging::Connection class as a string is "transport", while "protocol" refers to the AMQP protocol version. > Documentation states incorrect connection option for SSL > > > Key: QPID-5899 > URL: https://issues.apache.org/jira/browse/QPID-5899 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Chris Richardson >Priority: Minor > > The documentation for setting up SSL at > http://qpid.apache.org/releases/qpid-0.28/cpp-broker/book/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL > states: > "To open an SSL enabled connection in the Qpid Messaging API, set the > protocol connection option to ssl." > The correct connection option is "transport", not "protocol". -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5899) Documentation states incorrect connection option for SSL
Chris Richardson created QPID-5899: -- Summary: Documentation states incorrect connection option for SSL Key: QPID-5899 URL: https://issues.apache.org/jira/browse/QPID-5899 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.28 Reporter: Chris Richardson Priority: Minor The documentation for setting up SSL at http://qpid.apache.org/releases/qpid-0.28/cpp-broker/book/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL states: "To open an SSL enabled connection in the Qpid Messaging API, set the protocol connection option to ssl." The correct connection option is "transport", not "protocol". -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router
[
https://issues.apache.org/jira/browse/DISPATCH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson closed DISPATCH-40.
> Qdrouterd segfaults while connecting to neighbour router
>
>
> Key: DISPATCH-40
> URL: https://issues.apache.org/jira/browse/DISPATCH-40
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.1
> Environment: Ubuntu 12.04 LTS x86_64, Gentoo 32 and 64 bit
>Reporter: Chris Richardson
>Assignee: Ted Ross
> Fix For: 0.3
>
>
> Using the following configuration on two nodes (designated "client" and
> "server"), the client will segfault while connecting the server:
> {code}
> # Server config
> container {
>
>
>
> worker-threads: 4
>
>
>
> container-name: Qpid.Dispatch.Router.Server
>
>
>
> }
>
>
>
>
>
>
>
> ssl-profile {
>
>
>
> name: ssl-profile-name
>
>
>
> }
>
>
>
>
>
>
>
> listener {
>
>
>
> addr: 0.0.0.0
>
>
>
> port: amqp
>
>
>
> sasl-mechanisms: ANONYMOUS
>
>
>
> }
>
>
>
>
>
[jira] [Commented] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router
[
https://issues.apache.org/jira/browse/DISPATCH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955324#comment-13955324
]
Chris Richardson commented on DISPATCH-40:
--
Might be relevant - I built with the CMake system, not the config.h-based
system.
> Qdrouterd segfaults while connecting to neighbour router
>
>
> Key: DISPATCH-40
> URL: https://issues.apache.org/jira/browse/DISPATCH-40
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.1
> Environment: Ubuntu 12.04 LTS x86_64, Gentoo 32 and 64 bit
>Reporter: Chris Richardson
>Assignee: Ted Ross
>
> Using the following configuration on two nodes (designated "client" and
> "server"), the client will segfault while connecting the server:
> {code}
> # Server config
> container {
>
>
>
> worker-threads: 4
>
>
>
> container-name: Qpid.Dispatch.Router.Server
>
>
>
> }
>
>
>
>
>
>
>
> ssl-profile {
>
>
>
> name: ssl-profile-name
>
>
>
> }
>
>
>
>
>
>
>
> listener {
>
>
>
> addr: 0.0.0.0
>
>
>
> port: amqp
>
>
>
> sasl-mechanisms: ANONYMOUS
>
>
>
> }
>
>
>
>
[jira] [Updated] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router
[
https://issues.apache.org/jira/browse/DISPATCH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Richardson updated DISPATCH-40:
-
Description:
Using the following configuration on two nodes (designated "client" and
"server"), the client will segfault while connecting the server:
{code}
# Server config
container {
worker-threads: 4
container-name: Qpid.Dispatch.Router.Server
}
ssl-profile {
name: ssl-profile-name
}
listener {
addr: 0.0.0.0
port: amqp
sasl-mechanisms: ANONYMOUS
}
listener {
role: inter-router
[jira] [Created] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router
Chris Richardson created DISPATCH-40:
Summary: Qdrouterd segfaults while connecting to neighbour router
Key: DISPATCH-40
URL: https://issues.apache.org/jira/browse/DISPATCH-40
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.1
Environment: Ubuntu 12.04 LTS x86_64, Gentoo 32 and 64 bit
Reporter: Chris Richardson
Using the following configuration on two nodes (designated "client" and
"server"), the client will segfault while connecting the server:
{code}
# Server config
container {
worker-threads: 4
container-name: Qpid.Dispatch.Router.Server
}
ssl-profile {
name: ssl-profile-name
}
listener {
addr: 0.0.0.0
port: amqp
sasl-mechanisms: ANONYMOUS
}
listener {
