[jira] [Created] (QPID-8522) Intermittent unit test failure on Travis

[Chris Richardson (Jira)]

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 (Jira)]

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

[Chris Richardson (Jira)]

[ 
https://issues.apache.org/jira/browse/QPID-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (Jira)]

[ 
https://issues.apache.org/jira/browse/QPID-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (Jira)]

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

[Chris Richardson (Jira)]

 [ 
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

[Chris Richardson (Jira)]

 [ 
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 (Jira)]

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

[Chris Richardson (Jira)]

 [ 
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 (Jira)]

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 (JIRA)]

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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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*) 
>  ^~~
>  /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*) 
>  ^~ 
> {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

[Chris Richardson (JIRA)]

 [ 
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*) 
 ^~~
 /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*) 
 ^~ 
{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*) 
 ^~~
 /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*) 
 ^~ 
{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*) 
>  ^~~
>  /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*) 
>  ^~ 
> {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

[Chris Richardson (JIRA)]

 [ 
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*) 
 ^~~
 /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*) 
 ^~ 
{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*) 
 ^~~
/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*) 
 ^~~

 

 

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*) 
>  ^~~
>  /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*) 
>  ^~ 
> {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

[Chris Richardson (JIRA)]

 [ 
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 (JIRA)]

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*) 
 ^~~
/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*) 
 ^~~

 

 

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 (JIRA)]

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 (JIRA)]

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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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:

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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:

[Chris Richardson (JIRA)]

 [ 
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:

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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(::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(::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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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(::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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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. 
> 

[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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 

[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges

[Chris Richardson (JIRA)]

 [ 
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 

[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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 

[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges

[Chris Richardson (JIRA)]

 [ 
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:
> * 

[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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 (JIRA)]

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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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 (JIRA)]

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

[Chris Richardson (JIRA)]

 [ 
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 (JIRA)]

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 (JIRA)]

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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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 (JIRA)]

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 (JIRA)]

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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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

[Chris Richardson (JIRA)]

 [ 
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] [Created] (QPIDJMS-141) Thread sync error can cause long blocking delay after message send

[Chris Richardson (JIRA)]

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] [Commented] (QPIDJMS-141) Thread sync error can cause long blocking delay after message send

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Closed] (QPIDJMS-140) JmsMessage.copy method incorrectly assigns readOnlyBody to readOnlyProperties

[Chris Richardson (JIRA)]

 [ 
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] [Created] (QPIDJMS-140) Copy method incorrectly assigns readOnlyBody to readOnlyProperties

[Chris Richardson (JIRA)]

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] (QPIDJMS-140) JmsMessage.copy method incorrectly assigns readOnlyBody to readOnlyProperties

[Chris Richardson (JIRA)]

 [ 
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] [Updated] (QPID-6821) Python tools scripts should specify correct python version in shebang

[Chris Richardson (JIRA)]

 [ 
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 (JIRA)]

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

[Chris Richardson (JIRA)]

 [ 
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] [Created] (QPID-5927) Broker does not support whitespace in passwords in SSL password file

[Chris Richardson (JIRA)]

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] [Updated] (QPID-5927) Broker does not support whitespace in passwords in SSL password file

[Chris Richardson (JIRA)]

 [ 
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] [Commented] (QPID-5899) Documentation states incorrect connection option for SSL

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Comment Edited] (QPID-5899) Documentation states incorrect connection option for SSL

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (QPID-5899) Documentation states incorrect connection option for SSL

[Chris Richardson (JIRA)]

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

[Chris Richardson (JIRA)]

 [ 
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] [Created] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router

[Chris Richardson (JIRA)]

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 {  

[jira] [Updated] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router

[Chris Richardson (JIRA)]

 [ 
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] [Commented] (DISPATCH-40) Qdrouterd segfaults while connecting to neighbour router

[Chris Richardson (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
   
   
  
 }