[jira] [Updated] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated QPIDJMS-325:
---
Priority: Trivial  (was: Minor)

> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Danek
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



--
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] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-20 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-325:
--

 Summary: reading from empty buffer of a BytesMessage should return 
0, not -1
 Key: QPIDJMS-325
 URL: https://issues.apache.org/jira/browse/QPIDJMS-325
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.25.0
Reporter: Jiri Danek
Priority: Minor


Consider the following test. According to 
http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
 the #readBytes method should return 0 when it is first called, as the number 
of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
should return -1. What happens now is that the method returns -1 the first time.

See the commented lines to try the same thing with ActiveMQ JMS Client library, 
and with StreamMessage instead of BytesMessage. The behavior there should be 
the same.

ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
Qpid JMS fails with BytesMessage and passes with StreamMessage.

{code}
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.qpid.jms.JmsConnectionFactory;
import org.junit.Test;

import javax.jms.*;

import static com.google.common.truth.Truth.assertThat;

public class EmptyBufferInputTest {
@Test
public void testEmptyBufferInput() throws JMSException {
//ConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
JmsConnectionFactory connectionFactory = new 
JmsConnectionFactory("amqp://127.0.0.1:5672");
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
final byte[] BYTE_LIST = {1, 2, 4};
//StreamMessage message = session.createStreamMessage();
BytesMessage message = session.createBytesMessage();
message.clearBody();
byte[] readList = new byte[BYTE_LIST.length - 1];
byte[] emptyList = {};
message.writeBytes(emptyList);
message.reset();
final int IS_EMPTY = 0;
assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
}
}
{code}



--
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] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

2017-09-19 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1592:
--

 Summary: [proton-python] accessing properties of event.receiver in 
on_link_opened throws exception
 Key: PROTON-1592
 URL: https://issues.apache.org/jira/browse/PROTON-1592
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Reporter: Jiri Danek


Apply the following patch to the {{tx-recv.py}} example

{code}
diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
index 4baddcf5..54f3b489 100755
--- a/examples/python/tx_recv.py
+++ b/examples/python/tx_recv.py
@@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
 self.container.declare_transaction(self.conn, handler=self)
 self.transaction = None
 
+def on_link_opened(self, event):
+event.receiver.drain_mode = True
+
 def on_message(self, event):
 print(event.message.body)
 self.transaction.accept(event.delivery)
{noformat}

Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
throws exception

{noformat}
$ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
python ../examples/python/tx_recv.py
Traceback (most recent call last):
  File "../examples/python/tx_recv.py", line 79, in 
Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 148, in run
while self.process(): pass
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 174, in process
self._check_errors()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 170, in _check_errors
_compat.raise_(exc, value, tb)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 4068, in dispatch
ev.dispatch(self.handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3857, in dispatch
return handler.on_unhandled(method, *args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 876, in on_unhandled
event.dispatch(handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3980, in dispatch
self.dispatch(h, type)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 298, in on_link_remote_open
self.on_link_opened(event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 313, in on_link_opened
dispatch(self.delegate, 'on_link_opened', event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File "../examples/python/tx_recv.py", line 44, in on_link_opened
event.receiver.drain_mode = True
AttributeError: 'NoneType' object has no attribute 'drain_mode'
{noformat}

To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
Pypi. With this previous release, there is success.



--
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] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

2017-09-19 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1592:
---
Description: 
Apply the following patch to the {{tx-recv.py}} example

{code}
diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
index 4baddcf5..54f3b489 100755
--- a/examples/python/tx_recv.py
+++ b/examples/python/tx_recv.py
@@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
 self.container.declare_transaction(self.conn, handler=self)
 self.transaction = None
 
+def on_link_opened(self, event):
+event.receiver.drain_mode = True
+
 def on_message(self, event):
 print(event.message.body)
 self.transaction.accept(event.delivery)
{code}

Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
throws exception

{noformat}
$ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
python ../examples/python/tx_recv.py
Traceback (most recent call last):
  File "../examples/python/tx_recv.py", line 79, in 
Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 148, in run
while self.process(): pass
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 174, in process
self._check_errors()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 170, in _check_errors
_compat.raise_(exc, value, tb)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 4068, in dispatch
ev.dispatch(self.handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3857, in dispatch
return handler.on_unhandled(method, *args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 876, in on_unhandled
event.dispatch(handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3980, in dispatch
self.dispatch(h, type)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 298, in on_link_remote_open
self.on_link_opened(event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 313, in on_link_opened
dispatch(self.delegate, 'on_link_opened', event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File "../examples/python/tx_recv.py", line 44, in on_link_opened
event.receiver.drain_mode = True
AttributeError: 'NoneType' object has no attribute 'drain_mode'
{noformat}

To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
Pypi. With this previous release, there is success.

  was:
Apply the following patch to the {{tx-recv.py}} example

{code}
diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
index 4baddcf5..54f3b489 100755
--- a/examples/python/tx_recv.py
+++ b/examples/python/tx_recv.py
@@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
 self.container.declare_transaction(self.conn, handler=self)
 self.transaction = None
 
+def on_link_opened(self, event):
+event.receiver.drain_mode = True
+
 def on_message(self, event):
 print(event.message.body)
 self.transaction.accept(event.delivery)
{noformat}

Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
throws exception

{noformat}
$ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
python ../examples/python/tx_recv.py
Traceback (most recent call last):
  File "../examples/python/tx_recv.py", line 79, in 
Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 148, in run
while self.process(): pass
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 174, in process
self._check_errors()
  File 

[jira] [Commented] (PROTON-1591) [proton-cpp] Scheduling task from a scheduled task will deadlock

2017-09-18 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170653#comment-16170653
 ] 

Jiri Danek commented on PROTON-1591:


I am aware the reproducer may be wrong. 1) it does not worka 2) the example 
program {{cpp/scheduled_send.cpp}} does work and it is written somewhat 
differently

> [proton-cpp] Scheduling task from a scheduled task will deadlock
> 
>
> Key: PROTON-1591
> URL: https://issues.apache.org/jira/browse/PROTON-1591
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
> Environment: commit 6a57a8c986fbf86ad8ad109d673a89a5ae84c544 
> (upstream/master)
> Author: Cliff Jansen 
> Date:   Thu Sep 14 23:29:14 2017 -0700
> PROTON-1349: completed and improved implementation, but still fails many 
> tests
>Reporter: Jiri Danek
>Assignee: Cliff Jansen
>
> Modify the {{cpp/simple_send.cpp}} example the following way
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..92e60ee0 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -29,9 +29,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "fake_cpp11.hpp"
>  
> @@ -45,15 +47,28 @@ class simple_send : public proton::messaging_handler {
>  int confirmed;
>  int total;
>  
> +std::function callback;
> +
>public:
>  simple_send(const std::string , const std::string , const 
> std::string , int c) :
> -url(s), user(u), password(p), sent(0), confirmed(0), total(c) {}
> +url(s), user(u), password(p), sent(0), confirmed(0), total(c) {
> +callback = [this]() {
> +std::cout << "Entering callback" << std::endl;
> +//TODO: uncomment one of the two commands below
> +//
> +//sender.container().stop();
> +//sender.container().schedule(1 * proton::duration::SECOND, 
> proton::work(callback));
> +//
> +std::cout << "Leaving callback" << std::endl;
> +};
> +}
>  
>  void on_container_start(proton::container ) OVERRIDE {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
>  sender = c.open_sender(url, co);
> +c.schedule(1 * proton::duration::SECOND, proton::work(callback));
>  }
>  
>  void on_sendable(proton::sender ) OVERRIDE {
> {code}
> Now uncomment one of the two commented out commands. Either to stop the 
> container from the inside scheduled task, or to schedule new task from inside 
> the scheduled task. When executed, the program will deadlock.
> {noformat}
> Program received signal SIGINT, Interrupt.
> 0x768ef6dc in __lll_lock_wait () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> (gdb) bt
> #0  0x768ef6dc in __lll_lock_wait () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> #1  0x768e88e5 in pthread_mutex_lock () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> #2  0x77baf1e8 in __gthread_mutex_lock (__mutex=0x61e148) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:748
> #3  std::mutex::lock (this=0x61e148) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:103
> #4  std::lock_guard::lock_guard (__m=..., this= pointer>) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:162
> #5  proton::container::impl::schedule (this=this@entry=0x61e140, delay=..., 
> delay@entry=..., f=...) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:399
> #6  0x77baccc8 in proton::container::schedule 
> (this=this@entry=0x7fffc668, d=..., f=...) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container.cpp:109
> #7  0x004065f9 in 
> simple_send::simple_send(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string > const&, std::__cxx11::basic_string std::allocator > const&, int)::{lambda()#1}::operator()() const 
> (__closure=) at 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/simple_send.cpp:58
> #8  std::_Function_handler simple_send::simple_send(std::__cxx11::basic_string 

[jira] [Created] (PROTON-1591) [proton-cpp] Scheduling task from a scheduled task will deadlock

2017-09-18 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1591:
--

 Summary: [proton-cpp] Scheduling task from a scheduled task will 
deadlock
 Key: PROTON-1591
 URL: https://issues.apache.org/jira/browse/PROTON-1591
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
 Environment: commit 6a57a8c986fbf86ad8ad109d673a89a5ae84c544 
(upstream/master)
Author: Cliff Jansen 
Date:   Thu Sep 14 23:29:14 2017 -0700

PROTON-1349: completed and improved implementation, but still fails many 
tests
Reporter: Jiri Danek
Assignee: Cliff Jansen


Modify the {{cpp/simple_send.cpp}} example the following way

{code}
diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
index a4c2272d..92e60ee0 100644
--- a/examples/cpp/simple_send.cpp
+++ b/examples/cpp/simple_send.cpp
@@ -29,9 +29,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 
 #include "fake_cpp11.hpp"
 
@@ -45,15 +47,28 @@ class simple_send : public proton::messaging_handler {
 int confirmed;
 int total;
 
+std::function callback;
+
   public:
 simple_send(const std::string , const std::string , const std::string 
, int c) :
-url(s), user(u), password(p), sent(0), confirmed(0), total(c) {}
+url(s), user(u), password(p), sent(0), confirmed(0), total(c) {
+callback = [this]() {
+std::cout << "Entering callback" << std::endl;
+//TODO: uncomment one of the two commands below
+//
+//sender.container().stop();
+//sender.container().schedule(1 * proton::duration::SECOND, 
proton::work(callback));
+//
+std::cout << "Leaving callback" << std::endl;
+};
+}
 
 void on_container_start(proton::container ) OVERRIDE {
 proton::connection_options co;
 if (!user.empty()) co.user(user);
 if (!password.empty()) co.password(password);
 sender = c.open_sender(url, co);
+c.schedule(1 * proton::duration::SECOND, proton::work(callback));
 }
 
 void on_sendable(proton::sender ) OVERRIDE {
{code}

Now uncomment one of the two commented out commands. Either to stop the 
container from the inside scheduled task, or to schedule new task from inside 
the scheduled task. When executed, the program will deadlock.

{noformat}
Program received signal SIGINT, Interrupt.
0x768ef6dc in __lll_lock_wait () from 
/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
(gdb) bt
#0  0x768ef6dc in __lll_lock_wait () from 
/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
#1  0x768e88e5 in pthread_mutex_lock () from 
/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
#2  0x77baf1e8 in __gthread_mutex_lock (__mutex=0x61e148) at 
/nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:748
#3  std::mutex::lock (this=0x61e148) at 
/nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:103
#4  std::lock_guard::lock_guard (__m=..., this=) 
at 
/nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:162
#5  proton::container::impl::schedule (this=this@entry=0x61e140, delay=..., 
delay@entry=..., f=...) at 
/home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:399
#6  0x77baccc8 in proton::container::schedule 
(this=this@entry=0x7fffc668, d=..., f=...) at 
/home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container.cpp:109
#7  0x004065f9 in 
simple_send::simple_send(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string 
const&, std::__cxx11::basic_string const&, int)::{lambda()#1}::operator()() const 
(__closure=) at 
/home/jdanek/Work/repos/qpid-proton/examples/cpp/simple_send.cpp:58
#8  std::_Function_handler, std::allocator > const&, 
std::__cxx11::basic_string 
const&, std::__cxx11::basic_string const&, int)::{lambda()#1}>::_M_invoke(std::_Any_data 
const&) (__functor=...) at 
/nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:316
#9  0x77baf706 in std::function::operator()() const 
(this=) at 
/nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:706
#10 proton::work::operator() (this=) at 

[jira] [Created] (PROTON-1590) Segfault in proton-c++ when compiled with GCC 7.1.0 without any options and then used from project compiled with -stc=c++03

2017-09-18 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1590:
--

 Summary: Segfault in proton-c++ when compiled with GCC 7.1.0 
without any options and then used from project compiled with -stc=c++03
 Key: PROTON-1590
 URL: https://issues.apache.org/jira/browse/PROTON-1590
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.18.0
Reporter: Jiri Danek
Assignee: Cliff Jansen


Compile the proton library as usual.

{noformat}
cmake .. -DBUILD_GO=OFF -DCMAKE_INSTALL_PREFIX=../install -GNinja
ninja install
{noformat}

Now compile an application that uses container.schedule() function. An example 
should work fine.

{noformat}
g++ -std=c++03 scheduled_send_03.cpp -I ../../install/include -L 
../../install/lib64 -l qpid-proton-cpp -l qpid-proton-core -l 
qpid-proton-proactor
{noformat}

Run this and observe the segfault

{noformat}
LD_LIBRARY_PATH=../../install/lib64 ./a.out  
Segmentation fault
{noformat}

{noformat}
$ LD_LIBRARY_PATH=../../install/lib64 gdb --args ./a.out
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
[...]
Reading symbols from ./a.out...done.
(gdb) run
Starting program: /home/jdanek/Work/repos/qpid-proton/examples/cpp/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7fffae20 in ?? ()
(gdb) bt
#0  0x7fffae20 in ?? ()
#1  0x77bb09d4 in std::function::function(std::function const&) (this=0x7ffface0, __x=...)
at 
/nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:677
#2  0x77bc714a in proton::work::work (this=0x7ffface0) at 
../proton-c/bindings/cpp/include/proton/work_queue.hpp:47
#3  proton::work_queue::schedule (this=, d=..., f=...) at 
../proton-c/bindings/cpp/src/work_queue.cpp:49
#4  0x00405ade in void proton::schedule_work(proton::work_queue*, proton::duration, void 
(scheduled_sender::*)(proton::sender), scheduled_sender*, proton::sender) ()
#5  0x00405bfb in scheduled_sender::on_sender_open(proton::sender&) ()
#6  0x77bb8f3d in proton::(anonymous namespace)::on_link_remote_open 
(event=0x7fffb1a0, handler=warning: RTTI symbol not found for class 
'scheduled_sender'
...)
at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:267
#7  proton::messaging_adapter::dispatch (handler=warning: RTTI symbol not found 
for class 'scheduled_sender'
..., event=event@entry=0x61dcd0)
at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:309
#8  0x77bafa2e in proton::container::impl::handle 
(this=this@entry=0x61d030, event=0x61dcd0)
at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:601
#9  0x77bb006b in proton::container::impl::thread 
(this=this@entry=0x61d030)
at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:613
#10 0x77bb0413 in proton::container::impl::run (this=0x61d030, 
threads=1)
at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:651
#11 0x00404166 in main ()
{noformat}



--
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] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

2017-09-18 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170140#comment-16170140
 ] 

Jiri Danek commented on PROTON-1573:


I think this is resolved already. I'll look for the specific commit.

> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Danek
>Priority: Trivial
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth worrying about, unless the code can be somehow restructured that {{n = 
> 0}} is caught sooner. I verified the fix by running UBSan again. Nothing was 
> reported this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
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] (PROTON-1589) How can I handle invalid SASL PLAIN credentials error when reconnect is on?

2017-09-18 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1589:
---
Description: 
Apply the following patch to the simple_send.cpp example

{code}
diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
index a4c2272d..053da34f 100644
--- a/examples/cpp/simple_send.cpp
+++ b/examples/cpp/simple_send.cpp
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
 proton::connection_options co;
 if (!user.empty()) co.user(user);
 if (!password.empty()) co.password(password);
+co.sasl_enabled(true);
+co.sasl_allow_insecure_mechs(true);
+std::string sasl_mechanisms("PLAIN");
+co.sasl_allowed_mechs(sasl_mechanisms);
+proton::reconnect_options ro;
+co.reconnect(ro);
 sender = c.open_sender(url, co);
 }
{code}

Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
which was created with {{--require-login}}. The client gets stuck if you use 
invalid credentials.

{noformat}
PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
user
[0xed9980]:  -> SASL
[0xed9980]:  <- SASL
[0xed9980]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xed9980]:0 <- @sasl-outcome(68) [code=1]
[0xed9980]:  -> EOS
[0xee7290]:  -> SASL
[0xee7290]:  <- SASL
[0xee7290]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xee7290]:0 <- @sasl-outcome(68) [code=1]
[0xee7290]:  -> EOS
[0xeee6b0]:  -> SASL
[0xeee6b0]:  <- SASL
[0xeee6b0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
[0xeee6b0]:  -> EOS
{noformat}

As you can see, the client keeps reconnecting. The previous behavior, if I 
recall correctly, was to execute error handler in this case. To be exact, it 
would run {{on_transport_error}} handler.

I think that it is reasonable for the client to stop reconnecting and run this 
handler if the reason for failed connection are wrong credentials. This 
condition is unlikely to resolve itself on multiple retries.

  was:
Apply the following patch to the simple_send.cpp example

{code}
diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
index a4c2272d..053da34f 100644
--- a/examples/cpp/simple_send.cpp
+++ b/examples/cpp/simple_send.cpp
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
 proton::connection_options co;
 if (!user.empty()) co.user(user);
 if (!password.empty()) co.password(password);
+co.sasl_enabled(true);
+co.sasl_allow_insecure_mechs(true);
+std::string sasl_mechanisms("PLAIN");
+co.sasl_allowed_mechs(sasl_mechanisms);
+proton::reconnect_options ro;
+co.reconnect(ro);
 sender = c.open_sender(url, co);
 }
{noformat}

Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
which was created with {{--require-login}}. The client gets stuck if you use 
invalid credentials.

{noformat}
PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
user
[0xed9980]:  -> SASL
[0xed9980]:  <- SASL
[0xed9980]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xed9980]:0 <- @sasl-outcome(68) [code=1]
[0xed9980]:  -> EOS
[0xee7290]:  -> SASL
[0xee7290]:  <- SASL
[0xee7290]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xee7290]:0 <- @sasl-outcome(68) [code=1]
[0xee7290]:  -> EOS
[0xeee6b0]:  -> SASL
[0xeee6b0]:  <- SASL
[0xeee6b0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
[0xeee6b0]:  -> EOS
{noformat}

As you can see, the client keeps reconnecting. The previous behavior, if I 
recall correctly, was to execute error handler in this case. To be exact, it 
would run {{on_transport_error}} handler.

I think that it is reasonable for the client to stop reconnecting and run this 
handler if the reason for failed connection are wrong credentials. This 
condition is unlikely to resolve 

[jira] [Created] (PROTON-1589) How can I handle invalid SASL PLAIN credentials error when reconnect is on?

2017-09-18 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1589:
--

 Summary: How can I handle invalid SASL PLAIN credentials error 
when reconnect is on?
 Key: PROTON-1589
 URL: https://issues.apache.org/jira/browse/PROTON-1589
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.18.0
Reporter: Jiri Danek
Assignee: Cliff Jansen


Apply the following patch to the simple_send.cpp example

{code}
diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
index a4c2272d..053da34f 100644
--- a/examples/cpp/simple_send.cpp
+++ b/examples/cpp/simple_send.cpp
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
 proton::connection_options co;
 if (!user.empty()) co.user(user);
 if (!password.empty()) co.password(password);
+co.sasl_enabled(true);
+co.sasl_allow_insecure_mechs(true);
+std::string sasl_mechanisms("PLAIN");
+co.sasl_allowed_mechs(sasl_mechanisms);
+proton::reconnect_options ro;
+co.reconnect(ro);
 sender = c.open_sender(url, co);
 }
{noformat}

Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
which was created with {{--require-login}}. The client gets stuck if you use 
invalid credentials.

{noformat}
PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
user
[0xed9980]:  -> SASL
[0xed9980]:  <- SASL
[0xed9980]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xed9980]:0 <- @sasl-outcome(68) [code=1]
[0xed9980]:  -> EOS
[0xee7290]:  -> SASL
[0xee7290]:  <- SASL
[0xee7290]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xee7290]:0 <- @sasl-outcome(68) [code=1]
[0xee7290]:  -> EOS
[0xeee6b0]:  -> SASL
[0xeee6b0]:  <- SASL
[0xeee6b0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, 
:ANONYMOUS]]
[0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00nosuch\x00user"]
[0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
[0xeee6b0]:  -> EOS
{noformat}

As you can see, the client keeps reconnecting. The previous behavior, if I 
recall correctly, was to execute error handler in this case. To be exact, it 
would run {{on_transport_error}} handler.

I think that it is reasonable for the client to stop reconnecting and run this 
handler if the reason for failed connection are wrong credentials. This 
condition is unlikely to resolve itself on multiple retries.



--
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] (PROTON-1552) Epoll proactor example crash when given invalid hostname

2017-09-13 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1552:
---
Affects Version/s: proton-c-0.18.0

> Epoll proactor example crash when given invalid hostname
> 
>
> Key: PROTON-1552
> URL: https://issues.apache.org/jira/browse/PROTON-1552
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: qpid-proton at commit
> {noformat}
> commit 1b1f3f9cae1c68545f93c74e017edae039875440 (upstream/master)
> Author: Andrew Stitcher 
> Date:   Mon Aug 14 14:38:26 2017 -0400
> PROTON-1539: Ensure that SASL challenge and response frames generate a 
> binary
> - And never a null even if the binary is zero length
> {noformat}
>Reporter: Jiri Danek
>
> {noformat}
> [qpid-proton/build/examples/c/proactor]$ ./send upto.nogood.corp
> PN_TRANSPORT_CLOSED: proton:io: Name or service not known - connect to  
> upto.nogood.corp:5672 
>   
> epoll proactor failure in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:630: 
> "arming polled file descriptor": No such file or directory
>  
> Aborted
> {noformat}
> when compiled with libuv proactor, it does not crash
> {noformat}
> $ cmake -DPROACTOR=libuv -DBUILD_GO=OFF ..
> [/qpid-proton/build_libuv]$ examples/c/proactor/send upto.nogood
> PN_TRANSPORT_CLOSED: proton:io: unknown node or service - on connect 
> resolving upto.nogood:5672
> {noformat}
> {noformat}
> [jdanek@nixos:~/Work/repos/qpid-proton/build/examples/c/proactor]$ gdb --args 
> ./send upto.nogood.corp
> GNU gdb (GDB) 8.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> [...]
> (gdb) run
> Starting program: 
> /home/jdanek/Work/repos/qpid-proton/build/examples/c/proactor/send 
> upto.nogood.corp
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".
> PN_TRANSPORT_CLOSED: proton:io: Name or service not known - connect to  
> upto.nogood.corp:5672
> epoll proactor failure in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:630: 
> "arming polled file descriptor": No such file or directory
> Program received signal SIGABRT, Aborted.
> 0x7740e384 in raise () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6
> (gdb) bt
> #0  0x7740e384 in raise () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6
> #1  0x7740f7ea in abort () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6
> #2  0x77bd45de in rearm (p=, ee=) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:630
> #3  0x77bd5884 in pconnection_process (pc=0x6053c0, events= out>, timeout=, topup=) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1047
> #4  0x77bd52c4 in pconnection_batch_next (batch=) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:811
> #5  0x00401b98 in run (app=0x7fffd100) at 
> /home/jdanek/Work/repos/qpid-proton/examples/c/proactor/send.c:169
> #6  0x00401ff3 in main (argc=, argv=) 
> at /home/jdanek/Work/repos/qpid-proton/examples/c/proactor/send.c:192
> {noformat}



--
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] (DISPATCH-822) loss of SSL connection breaks other SSL connections

2017-09-12 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162856#comment-16162856
 ] 

Jiri Danek commented on DISPATCH-822:
-

Sounds a lot like DISPATCH-752.

> loss of SSL connection breaks other SSL connections
> ---
>
> Key: DISPATCH-822
> URL: https://issues.apache.org/jira/browse/DISPATCH-822
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: DISPATCH-822-reproducer.tgz
>
>
> It appears that losing an SSL connection has some as yet unexplained effect 
> on other SSL connections from the same router (though to totally different 
> processes, and triggered by a different connector).



--
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] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-09-08 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158770#comment-16158770
 ] 

Jiri Danek edited comment on PROTON-1540 at 9/8/17 3:17 PM:


[~aconway] The only way I can think of is to create a "custom python 
interpreter" using libpython, which would run the tests. It should be possible 
to modify some embedded python tutorial to do this. This custom interpreter can 
then be linked with the sanitizers and should not need LD_PRELOAD.

I do not know how to detect path to sanitizer libs in CMake, in a portable way. 
Having users confiture LD_PRELOAD for themselves is OK, I think.

In case of go, there is https://golang.org/doc/articles/race_detector.html. It 
should be possible to enable that somehow in the build. I will try to have a 
look at it.


was (Author: jdanek):
[~aconway] The only way I can think of is to create a "custom python 
interpreter" using libpython, which would run the tests. It should be possible 
to modify some embedded python tutorial to do this. This custom interpreter can 
then be linked with the sanitizers and should not need LD_PRELOAD.

I do not know how to detect path to sanitizer libs in CMake, in a portable way.

In case of go, there is https://golang.org/doc/articles/race_detector.html. It 
should be possible to enable that somehow in the build. I will try to have a 
look at it.

> Add options to enable Sanitizers to CMake build
> ---
>
> Key: PROTON-1540
> URL: https://issues.apache.org/jira/browse/PROTON-1540
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Reporter: Jiri Danek
>Assignee: Alan Conway
>Priority: Minor
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> To get the most out of sanitizers in Qpid Dispatch, it helps to compile 
> Proton with sanitizers as well.



--
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] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-09-08 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158770#comment-16158770
 ] 

Jiri Danek commented on PROTON-1540:


[~aconway] The only way I can think of is to create a "custom python 
interpreter" using libpython, which would run the tests. It should be possible 
to modify some embedded python tutorial to do this. This custom interpreter can 
then be linked with the sanitizers and should not need LD_PRELOAD.

I do not know how to detect path to sanitizer libs in CMake, in a portable way.

In case of go, there is https://golang.org/doc/articles/race_detector.html. It 
should be possible to enable that somehow in the build. I will try to have a 
look at it.

> Add options to enable Sanitizers to CMake build
> ---
>
> Key: PROTON-1540
> URL: https://issues.apache.org/jira/browse/PROTON-1540
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Reporter: Jiri Danek
>Assignee: Alan Conway
>Priority: Minor
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> To get the most out of sanitizers in Qpid Dispatch, it helps to compile 
> Proton with sanitizers as well.



--
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] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-09-07 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156617#comment-16156617
 ] 

Jiri Danek edited comment on PROTON-1540 at 9/7/17 8:14 AM:


Even with your options propagation fix, I still have this message coming from 
python-qpid-proton tests. Which I think is completely expected. There Python 
starts first, and it then loads the Proton lib when it is imported from Python 
code.

{noformat}
1: ==488==ASan runtime does not come first in initial library list; you should 
either link runtime to your application or manually preload it with LD_PRELOAD.
{noformat}

So, ctest should be running with LD_PRELOAD, or at least the python that is 
running the 1: tests, and then the sanitizer can sanitize the Python binding 
too.

There seem to be leaks in that. See PROTON-1575 for report and what I believe 
is helpful command to isolate the leaks to individual tests (otherwise all are 
reported at the end when Python exits).


was (Author: jdanek):
Even with your options propagation fix, I still have this message coming from 
python-qpid-proton tests. Which I think is completely expected. There Python 
starts first, and it then loads the Proton lib when it is imported from Python 
code.

{noformat}
1: ==488==ASan runtime does not come first in initial library list; you should 
either link runtime to your application or manually preload it with LD_PRELOAD.
{noformat}

So, ctest should be running with LD_PRELOAD, or at least the python that is 
running the 1: tests, and then the sanitizer can sanitize the Python binding 
too.

There seem to be leaks in that. See ?? for report and what I believe is helpful 
command to isolate the leaks to individual tests (otherwise all are reported at 
the end when Python exits).

> Add options to enable Sanitizers to CMake build
> ---
>
> Key: PROTON-1540
> URL: https://issues.apache.org/jira/browse/PROTON-1540
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Reporter: Jiri Danek
>Assignee: Alan Conway
>Priority: Minor
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> To get the most out of sanitizers in Qpid Dispatch, it helps to compile 
> Proton with sanitizers as well.



--
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] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-09-07 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156617#comment-16156617
 ] 

Jiri Danek commented on PROTON-1540:


Even with your options propagation fix, I still have this message coming from 
python-qpid-proton tests. Which I think is completely expected. There Python 
starts first, and it then loads the Proton lib when it is imported from Python 
code.

{noformat}
1: ==488==ASan runtime does not come first in initial library list; you should 
either link runtime to your application or manually preload it with LD_PRELOAD.
{noformat}

So, ctest should be running with LD_PRELOAD, or at least the python that is 
running the 1: tests, and then the sanitizer can sanitize the Python binding 
too.

There seem to be leaks in that. See ?? for report and what I believe is helpful 
command to isolate the leaks to individual tests (otherwise all are reported at 
the end when Python exits).

> Add options to enable Sanitizers to CMake build
> ---
>
> Key: PROTON-1540
> URL: https://issues.apache.org/jira/browse/PROTON-1540
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Reporter: Jiri Danek
>Assignee: Alan Conway
>Priority: Minor
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> To get the most out of sanitizers in Qpid Dispatch, it helps to compile 
> Proton with sanitizers as well.



--
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] (QPIDIT-93) Optionally produce xUnit XML report with test results

2017-09-06 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDIT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated QPIDIT-93:
-
Issue Type: Improvement  (was: Bug)

> Optionally produce xUnit XML report with test results
> -
>
> Key: QPIDIT-93
> URL: https://issues.apache.org/jira/browse/QPIDIT-93
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>Affects Versions: 0.1.0-SNAPSHOT
>Reporter: Jiri Danek
>
> Something like the following should do the job. Instead of 
> https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to 
> maybe switch from unittest package to py.test, which has xUnit reports built 
> in.
> {noformat}
> diff --git a/src/python/qpid_interop_test/jms_messages_test.py 
> b/src/python/qpid_interop_test/jms_messages_test.py
> index 3b54510..3b94f3a 100755
> --- a/src/python/qpid_interop_test/jms_messages_test.py
> +++ b/src/python/qpid_interop_test/jms_messages_test.py
> @@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
>  from json import dumps
>  from os import getenv, path
> +import xmlrunner
>  from proton import symbol
>  from qpid_interop_test.test_type_map import TestTypeMap
> @@ -302,7 +300,7 @@ class TestOptions(object):
>  Class controlling command-line arguments used to control the test.
>  """
>  def __init__(self, shim_map):
> -parser = argparse.ArgumentParser(description='Qpid-interop AMQP 
> client interoparability test suite '
> +parser = argparse.ArgumentParser(description='Qpid-interop AMQP 
> client interoperability test suite '
>   'for JMS message types')
>  parser.add_argument('--sender', action='store', 
> default='localhost:5672', metavar='IP-ADDR:PORT',
>  help='Node to which test suite will send 
> messages.')
> @@ -313,6 +311,8 @@ class TestOptions(object):
>  parser.add_argument('--broker-type', action='store', 
> metavar='BROKER_NAME',
>  help='Disable test of broker type (using 
> connection properties) by specifying the broker' +
>  ' name, or "None".')
> +parser.add_argument('--xunit-report-dir', action='store', 
> metavar='REPORTS_DIRECTORY',
> +help='Generate xUnit report into 
> REPORTS_DIRECTORY/TEST--.xml')
>  type_group = parser.add_mutually_exclusive_group()
>  type_group.add_argument('--include-type', action='append', 
> metavar='JMS_MESSAGE-TYPE',
>  help='Name of JMS message type to include. 
> Supported types:\n%s' %
> @@ -421,6 +421,7 @@ if __name__ == '__main__':
>  TEST_SUITE.addTest(unittest.makeSuite(test_case_class))
>  
>  # Finally, run all the dynamically created tests
> -RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)
> +#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
> unittest.TextTestResult
> +RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
> unittest.TextTestResult
>  if not RES.wasSuccessful():
>  sys.exit(1)
> {noformat}
> The main "problem" seems that each test has completely separate main method 
> and builds up options from scratch. Adding this to every test would mean some 
> unnecessary duplication. So maybe refactor this somewhat at first? On the 
> other hand, there are good reasons to keep the tests simple...
> What do you think?



--
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] (QPIDIT-93) Optionally produce xUnit XML report with test results

2017-09-06 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDIT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated QPIDIT-93:
-
Description: 
Something like the following should do the job. Instead of 
https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to 
maybe switch from unittest package to py.test, which has xUnit reports built in.

{noformat}
diff --git a/src/python/qpid_interop_test/jms_messages_test.py 
b/src/python/qpid_interop_test/jms_messages_test.py
index 3b54510..3b94f3a 100755
--- a/src/python/qpid_interop_test/jms_messages_test.py
+++ b/src/python/qpid_interop_test/jms_messages_test.py
@@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
 from json import dumps
 from os import getenv, path

+import xmlrunner

 from proton import symbol
 from qpid_interop_test.test_type_map import TestTypeMap
@@ -302,7 +300,7 @@ class TestOptions(object):
 Class controlling command-line arguments used to control the test.
 """
 def __init__(self, shim_map):
-parser = argparse.ArgumentParser(description='Qpid-interop AMQP client 
interoparability test suite '
+parser = argparse.ArgumentParser(description='Qpid-interop AMQP client 
interoperability test suite '
  'for JMS message types')
 parser.add_argument('--sender', action='store', 
default='localhost:5672', metavar='IP-ADDR:PORT',
 help='Node to which test suite will send 
messages.')
@@ -313,6 +311,8 @@ class TestOptions(object):
 parser.add_argument('--broker-type', action='store', 
metavar='BROKER_NAME',
 help='Disable test of broker type (using 
connection properties) by specifying the broker' +
 ' name, or "None".')
+parser.add_argument('--xunit-report-dir', action='store', 
metavar='REPORTS_DIRECTORY',
+help='Generate xUnit report into 
REPORTS_DIRECTORY/TEST--.xml')
 type_group = parser.add_mutually_exclusive_group()
 type_group.add_argument('--include-type', action='append', 
metavar='JMS_MESSAGE-TYPE',
 help='Name of JMS message type to include. 
Supported types:\n%s' %
@@ -421,6 +421,7 @@ if __name__ == '__main__':
 TEST_SUITE.addTest(unittest.makeSuite(test_case_class))
 
 # Finally, run all the dynamically created tests
-RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)
+#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
unittest.TextTestResult
+RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
unittest.TextTestResult
 if not RES.wasSuccessful():
 sys.exit(1)
{noformat}

The main "problem" seems that each test has completely separate main method and 
builds up options from scratch. Adding this to every test would mean some 
unnecessary duplication. So maybe refactor this somewhat at first? On the other 
hand, there are good reasons to keep the tests simple...

What do you think?

  was:
Something like the following should do the job. Instead of 
https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to 
maybe switch from unittest package to py.test, which has xUnit reports built in.

{code}
diff --git a/src/python/qpid_interop_test/jms_messages_test.py 
b/src/python/qpid_interop_test/jms_messages_test.py
index 3b54510..3b94f3a 100755
--- a/src/python/qpid_interop_test/jms_messages_test.py
+++ b/src/python/qpid_interop_test/jms_messages_test.py
@@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
 from json import dumps
 from os import getenv, path

+import xmlrunner

 from proton import symbol
 from qpid_interop_test.test_type_map import TestTypeMap
@@ -302,7 +300,7 @@ class TestOptions(object):
 Class controlling command-line arguments used to control the test.
 """
 def __init__(self, shim_map):
-parser = argparse.ArgumentParser(description='Qpid-interop AMQP client 
interoparability test suite '
+parser = argparse.ArgumentParser(description='Qpid-interop AMQP client 
interoperability test suite '
  'for JMS message types')
 parser.add_argument('--sender', action='store', 
default='localhost:5672', metavar='IP-ADDR:PORT',
 help='Node to which test suite will send 
messages.')
@@ -313,6 +311,8 @@ class TestOptions(object):
 parser.add_argument('--broker-type', action='store', 
metavar='BROKER_NAME',
 help='Disable test of broker type (using 
connection properties) by specifying the broker' +
 ' name, or "None".')
+parser.add_argument('--xunit-report-dir', action='store', 
metavar='REPORTS_DIRECTORY',
+help='Generate xUnit report into 

[jira] [Created] (QPIDIT-93) Optionally produce xUnit XML report with test results

2017-09-06 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDIT-93:


 Summary: Optionally produce xUnit XML report with test results
 Key: QPIDIT-93
 URL: https://issues.apache.org/jira/browse/QPIDIT-93
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Bug
Affects Versions: 0.1.0-SNAPSHOT
Reporter: Jiri Danek


Something like the following should do the job. Instead of 
https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to 
maybe switch from unittest package to py.test, which has xUnit reports built in.

{code}
diff --git a/src/python/qpid_interop_test/jms_messages_test.py 
b/src/python/qpid_interop_test/jms_messages_test.py
index 3b54510..3b94f3a 100755
--- a/src/python/qpid_interop_test/jms_messages_test.py
+++ b/src/python/qpid_interop_test/jms_messages_test.py
@@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
 from json import dumps
 from os import getenv, path

+import xmlrunner

 from proton import symbol
 from qpid_interop_test.test_type_map import TestTypeMap
@@ -302,7 +300,7 @@ class TestOptions(object):
 Class controlling command-line arguments used to control the test.
 """
 def __init__(self, shim_map):
-parser = argparse.ArgumentParser(description='Qpid-interop AMQP client 
interoparability test suite '
+parser = argparse.ArgumentParser(description='Qpid-interop AMQP client 
interoperability test suite '
  'for JMS message types')
 parser.add_argument('--sender', action='store', 
default='localhost:5672', metavar='IP-ADDR:PORT',
 help='Node to which test suite will send 
messages.')
@@ -313,6 +311,8 @@ class TestOptions(object):
 parser.add_argument('--broker-type', action='store', 
metavar='BROKER_NAME',
 help='Disable test of broker type (using 
connection properties) by specifying the broker' +
 ' name, or "None".')
+parser.add_argument('--xunit-report-dir', action='store', 
metavar='REPORTS_DIRECTORY',
+help='Generate xUnit report into 
REPORTS_DIRECTORY/TEST--.xml')
 type_group = parser.add_mutually_exclusive_group()
 type_group.add_argument('--include-type', action='append', 
metavar='JMS_MESSAGE-TYPE',
 help='Name of JMS message type to include. 
Supported types:\n%s' %
@@ -421,6 +421,7 @@ if __name__ == '__main__':
 TEST_SUITE.addTest(unittest.makeSuite(test_case_class))
 
 # Finally, run all the dynamically created tests
-RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)
+#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
unittest.TextTestResult
+RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
unittest.TextTestResult
 if not RES.wasSuccessful():
 sys.exit(1)
{code}

The main "problem" seems that each test has completely separate main method and 
builds up options from scratch. Adding this to every test would mean some 
unnecessary duplication. So maybe refactor this somewhat at first? On the other 
hand, there are good reasons to keep the tests simple...

What do you think?



--
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] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-09-05 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154836#comment-16154836
 ] 

Jiri Danek commented on PROTON-1540:


One addition. It is best to always run sanitizers with LD_PRELOAD. ASan will 
refuse to run if it is not loaded as the first thing. TSan can live with that, 
but it will find less issues. This is relevant when there is mixing of Python 
and C (and Python starts first). Some of it is in Proton tests (for Proton 
Python).

{noformat}
LD_PRELOAD=/path/to/gcc-7.1.0-lib/lib/libtsan.so TSAN_OPTIONS="color=always 
second_deadlock_stack=1" ctest -VV
{noformat}

> Add options to enable Sanitizers to CMake build
> ---
>
> Key: PROTON-1540
> URL: https://issues.apache.org/jira/browse/PROTON-1540
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Reporter: Jiri Danek
>Assignee: Alan Conway
>Priority: Minor
>
> To get the most out of sanitizers in Qpid Dispatch, it helps to compile 
> Proton with sanitizers as well.



--
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] (PROTON-1574) WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) due to missing unlock in stop_polling()

2017-09-05 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1574:
--

 Summary: WARNING: ThreadSanitizer: lock-order-inversion (potential 
deadlock) due to missing unlock in stop_polling()
 Key: PROTON-1574
 URL: https://issues.apache.org/jira/browse/PROTON-1574
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: proton-c-0.18.0
Reporter: Jiri Danek


There is a lot of warnings about lock order on proton tests, that all result 
from a missing unlock in {{stop_polling()}}.

{code}
diff --git a/proton-c/src/proactor/epoll.c b/proton-c/src/proactor/epoll.c 
index 46effcc7..887327dc 100644 
--- a/proton-c/src/proactor/epoll.c 
+++ b/proton-c/src/proactor/epoll.c 
@@ -296,8 +296,10 @@ static bool start_polling(epoll_extended_t *ee, int 
epollfd) { 
static void stop_polling(epoll_extended_t *ee, int epollfd) { 
  // TODO: check for error, return bool or just log? 
  lock(>mutex); 
-  if (ee->fd == -1 || !ee->polling || epollfd == -1) 
+  if (ee->fd == -1 || !ee->polling || epollfd == -1) { 
+unlock(>mutex); 
return; 
+  } 
  struct epoll_event ev; 
  ev.data.ptr = ee; 
  ev.events = 0;
{code}

The warnings follow. TSan is enabled as described in PROTON-1540.

{noformat}
$ LD_PRELOAD=/path/to/gcc-7.1.0-lib/lib/libtsan.so TSAN_OPTIONS="color=always 
second_deadlock_stack=1" ctest -VV

[...]

21: Test command: 
/home/jdanek/Work/repos/qpid-proton/build/proton-c/src/tests/c-proactor-tests 
21: Test timeout computed to be: 1500 
21: TEST: test_inactive() 
21: TEST: test_interrupt_timeout() 
21: TEST: test_errors() 
21: TEST: test_client_server() 
21: TEST: test_connection_wake() 
21: == 
21: WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) 
(pid=687) 
21:   Cycle in lock order graph: M170 (0x7b7014a0) => M173 (0x7b701558) 
=> M170 


21:  
21:   Mutex M173 acquired here while holding mutex M170 in main thread: 
21: #0 pthread_mutex_lock  (libtsan.so.0+0x000385df)  



21: #1 lock 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:112 
(libqpid-proton.so.11+0x00044f10) 
21: #2 start_polling 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:286 
(libqpid-proton.so.11+0x00044f10) 
21: #3 start_polling 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1194 
(libqpid-proton.so.11+0x0004513e) 
21: #4 pconnection_start 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1178 
(libqpid-proton.so.11+0x0004513e) 
21: #5 pn_listener_accept 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1611 
(libqpid-proton.so.11+0x00048cf2) 
21: #6 listen_handler 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:328 
(c-proactor-tests+0x00405720) 
21: #7 test_proactors_get 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:167 
(c-proactor-tests+0x00407490) 
21: #8 test_proactors_run 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:183 
(c-proactor-tests+0x0040bf84) 
21: #9 test_connection_wake 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:397 
(c-proactor-tests+0x0040bf84) 
21: #10 main 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:1066 
(c-proactor-tests+0x00404371) 
21:  
21:   Mutex M170 previously acquired by the same thread here: 
21: #0 pthread_mutex_lock  (libtsan.so.0+0x000385df) 
21: #1 lock 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:112 
(libqpid-proton.so.11+0x00048cd3) 
21: #2 pn_listener_accept 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1608 
(libqpid-proton.so.11+0x00048cd3) 
21: #3 listen_handler 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:328 
(c-proactor-tests+0x00405720) 
21: #4 test_proactors_get 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:167 
(c-proactor-tests+0x00407490) 
21: #5 test_proactors_run 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:183 
(c-proactor-tests+0x0040bf84) 
21: #6 test_connection_wake 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:397 
(c-proactor-tests+0x0040bf84) 
21: #7 main 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:1066 
(c-proactor-tests+0x00404371) 
21:  
21:   Mutex M170 acquired here while holding mutex M173 in main thread: 
21: #0 pthread_mutex_lock  

[jira] [Updated] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

2017-09-05 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1573:
---
Description: 
Proton sometimes calls to memmove with arguments memmove(?, null, 0), that is, 
the source pointer is null and length is zero.

According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
behavior.

{noformat}
SUMMARY: AddressSanitizer: undefined-behavior 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: runtime 
error: null pointer passed as argument 2, which is declared to never be null
{noformat}

It can be "fixed" in the following manner, but I think it is probably not worth 
worrying about, unless the code can be somehow restructured that {{n = 0}} is 
caught sooner. I verified the fix by running UBSan again. Nothing was reported 
this time.

{noformat}
diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
index c3015f49..f47acd6d 100644
--- a/proton-c/src/core/buffer.c
+++ b/proton-c/src/core/buffer.c
@@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char *bytes, 
size_t size)
   size_t tail_space = pni_buffer_tail_space(buf);
   size_t n = pn_min(tail_space, size);
 
+  if (n > 0) {
   memmove(buf->bytes + tail, bytes, n);
+  }
+  if (size - n > 0) { 
   memmove(buf->bytes, bytes + n, size - n);
+  }
 
   buf->size += size;
 
diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
index 09bf4bba..d2c355f8 100644
--- a/proton-c/src/core/framing.c
+++ b/proton-c/src/core/framing.c
@@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
pn_frame_t frame)
 bytes[5] = frame.type;
 pn_i_write16([6], frame.channel);
 
-memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+if (frame.ex_size > 0) {
+memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+}
 memmove(bytes + 4*doff, frame.payload, frame.size);
 return size;
   } else {
{noformat}

After brief Googling, I believe that although this really is an undefined 
behavior, it is reasonable to expect that any real-world implementation of 
memmove will be a simple noop as long as {{n = 0}}, which it is always the 
case. (https://stackoverflow.com/a/5243068/1047788)

Probably best to ignore this.

The tests that uncover this are for example

proton_tests.engine.ConnectionTest.test_capabilities:
../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
argument 2, which is declared to never be null

proton_tests.engine.CreditTest.testPartialDrain:
../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
argument 2, which is declared to never be null
../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
argument 2, which is declared to never be null


  was:
Proton sometimes calls to memmove with arguments memmove(?, null, 0), that is, 
the source pointer is null and length is zero.

According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
behavior.

{noformat}
SUMMARY: AddressSanitizer: undefined-behavior 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: runtime 
error: null pointer passed as argument 2, which is declared to never be null
{noformat}

It can be "fixed" in the following manner, but I think it is probably not worth 
it. I verified the fix by running UBSan again. Nothing was reported this time.

{noformat}
diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
index c3015f49..f47acd6d 100644
--- a/proton-c/src/core/buffer.c
+++ b/proton-c/src/core/buffer.c
@@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char *bytes, 
size_t size)
   size_t tail_space = pni_buffer_tail_space(buf);
   size_t n = pn_min(tail_space, size);
 
+  if (n > 0) {
   memmove(buf->bytes + tail, bytes, n);
+  }
+  if (size - n > 0) { 
   memmove(buf->bytes, bytes + n, size - n);
+  }
 
   buf->size += size;
 
diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
index 09bf4bba..d2c355f8 100644
--- a/proton-c/src/core/framing.c
+++ b/proton-c/src/core/framing.c
@@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
pn_frame_t frame)
 bytes[5] = frame.type;
 pn_i_write16([6], frame.channel);
 
-memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+if (frame.ex_size > 0) {
+memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+}
 memmove(bytes + 4*doff, frame.payload, frame.size);
 return size;
   } else {
{noformat}

After brief Googling, I believe that although this really is an undefined 
behavior, it is reasonable to expect that any real-world implementation of 
memmove will be a simple noop as long as {{n = 0}}, which it is always the 
case. 

[jira] [Updated] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

2017-09-05 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1573:
---
Description: 
Proton sometimes calls to memmove with arguments memmove(?, null, 0), that is, 
the source pointer is null and length is zero.

According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
behavior.

{noformat}
SUMMARY: AddressSanitizer: undefined-behavior 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: runtime 
error: null pointer passed as argument 2, which is declared to never be null
{noformat}

It can be "fixed" in the following manner, but I think it is probably not worth 
it. I verified the fix by running UBSan again. Nothing was reported this time.

{noformat}
diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
index c3015f49..f47acd6d 100644
--- a/proton-c/src/core/buffer.c
+++ b/proton-c/src/core/buffer.c
@@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char *bytes, 
size_t size)
   size_t tail_space = pni_buffer_tail_space(buf);
   size_t n = pn_min(tail_space, size);
 
+  if (n > 0) {
   memmove(buf->bytes + tail, bytes, n);
+  }
+  if (size - n > 0) { 
   memmove(buf->bytes, bytes + n, size - n);
+  }
 
   buf->size += size;
 
diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
index 09bf4bba..d2c355f8 100644
--- a/proton-c/src/core/framing.c
+++ b/proton-c/src/core/framing.c
@@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
pn_frame_t frame)
 bytes[5] = frame.type;
 pn_i_write16([6], frame.channel);
 
-memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+if (frame.ex_size > 0) {
+memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+}
 memmove(bytes + 4*doff, frame.payload, frame.size);
 return size;
   } else {
{noformat}

After brief Googling, I believe that although this really is an undefined 
behavior, it is reasonable to expect that any real-world implementation of 
memmove will be a simple noop as long as {{n = 0}}, which it is always the 
case. (https://stackoverflow.com/a/5243068/1047788)

Probably best to ignore this.

The tests that uncover this are for example

proton_tests.engine.ConnectionTest.test_capabilities:
../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
argument 2, which is declared to never be null

proton_tests.engine.CreditTest.testPartialDrain:
../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
argument 2, which is declared to never be null
../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
argument 2, which is declared to never be null


  was:
Proton sometimes calls to memmove with arguments memmove(?, null, 0), that is, 
the source pointer is null and length is zero.

According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
behavior.

{noformat}
SUMMARY: AddressSanitizer: undefined-behavior 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: runtime 
error: null pointer passed as argument 2, which is declared to never be null
{noformat}

It can be "fixed" in the following manner, but I think it is probably not worth 
it. I verified the fix by running UBSan again. Nothing was reported this time.

{noformat}
diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
index c3015f49..f47acd6d 100644
--- a/proton-c/src/core/buffer.c
+++ b/proton-c/src/core/buffer.c
@@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char *bytes, 
size_t size)
   size_t tail_space = pni_buffer_tail_space(buf);
   size_t n = pn_min(tail_space, size);
 
+  if (n > 0) {
   memmove(buf->bytes + tail, bytes, n);
+  }
+  if (size - n > 0) { 
   memmove(buf->bytes, bytes + n, size - n);
+  }
 
   buf->size += size;
 
diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
index 09bf4bba..d2c355f8 100644
--- a/proton-c/src/core/framing.c
+++ b/proton-c/src/core/framing.c
@@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
pn_frame_t frame)
 bytes[5] = frame.type;
 pn_i_write16([6], frame.channel);
 
-memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+if (frame.ex_size > 0) {
+memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+}
 memmove(bytes + 4*doff, frame.payload, frame.size);
 return size;
   } else {
{noformat}

After brief Googling, I believe that although this really is an undefined 
behavior, it is reasonable to expect that any real-world implementation of 
memmove will be a simple noop as long as n = 0, which it is always the case. 
(https://stackoverflow.com/a/5243068/1047788)

Probably best to ignore this.


> Undefined 

[jira] [Updated] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

2017-09-05 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1573:
---
Priority: Trivial  (was: Major)

> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Danek
>Priority: Trivial
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth it. I verified the fix by running UBSan again. Nothing was reported 
> this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
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] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

2017-09-05 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1573:
--

 Summary: Undefined behavior in some calls to memmove in Proton
 Key: PROTON-1573
 URL: https://issues.apache.org/jira/browse/PROTON-1573
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: proton-c-0.18.0
Reporter: Jiri Danek


Proton sometimes calls to memmove with arguments memmove(?, null, 0), that is, 
the source pointer is null and length is zero.

According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
behavior.

{noformat}
SUMMARY: AddressSanitizer: undefined-behavior 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: runtime 
error: null pointer passed as argument 2, which is declared to never be null
{noformat}

It can be "fixed" in the following manner, but I think it is probably not worth 
it. I verified the fix by running UBSan again. Nothing was reported this time.

{noformat}
diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
index c3015f49..f47acd6d 100644
--- a/proton-c/src/core/buffer.c
+++ b/proton-c/src/core/buffer.c
@@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char *bytes, 
size_t size)
   size_t tail_space = pni_buffer_tail_space(buf);
   size_t n = pn_min(tail_space, size);
 
+  if (n > 0) {
   memmove(buf->bytes + tail, bytes, n);
+  }
+  if (size - n > 0) { 
   memmove(buf->bytes, bytes + n, size - n);
+  }
 
   buf->size += size;
 
diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
index 09bf4bba..d2c355f8 100644
--- a/proton-c/src/core/framing.c
+++ b/proton-c/src/core/framing.c
@@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
pn_frame_t frame)
 bytes[5] = frame.type;
 pn_i_write16([6], frame.channel);
 
-memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+if (frame.ex_size > 0) {
+memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
+}
 memmove(bytes + 4*doff, frame.payload, frame.size);
 return size;
   } else {
{noformat}

After brief Googling, I believe that although this really is an undefined 
behavior, it is reasonable to expect that any real-world implementation of 
memmove will be a simple noop as long as n = 0, which it is always the case. 
(https://stackoverflow.com/a/5243068/1047788)

Probably best to ignore this.



--
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] (PROTON-1572) CppCheck 1.8 warnings

2017-09-05 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154262#comment-16154262
 ] 

Jiri Danek commented on PROTON-1572:


I think this should not be closed yet, there are (at least) these following 
messages that should be investigated.

{code}
diff --git a/examples/c/proactor/broker.c b/examples/c/proactor/broker.c
index e0d96720..84b8528a 100644
--- a/examples/c/proactor/broker.c
+++ b/examples/c/proactor/broker.c
@@ -364,8 +364,6 @@ static void handle(broker_t* b, pn_event_t* e) {
 broker_stop(b);
 break;
 
- break;
-
case PN_PROACTOR_INACTIVE:   /* listener and all connections closed */
 broker_stop(b);
 break;
diff --git a/proton-c/src/core/codec.c b/proton-c/src/core/codec.c
index 3417c94f..664a57e4 100644
--- a/proton-c/src/core/codec.c
+++ b/proton-c/src/core/codec.c
@@ -1360,7 +1360,7 @@ void pn_data_dump(pn_data_t *data)
 pni_node_t *node = >nodes[i];
 pn_string_set(data->str, "");
 pni_inspect_atom((pn_atom_t *) >atom, data->str);
-printf("Node %i: prev=%" PN_ZI ", next=%" PN_ZI ", parent=%" PN_ZI ", 
down=%" PN_ZI 
+printf("Node %u: prev=%" PN_ZI ", next=%" PN_ZI ", parent=%" PN_ZI ", 
down=%" PN_ZI 
", children=%" PN_ZI ", type=%s (%s)\n",
i + 1, (size_t) node->prev,
(size_t) node->next,
diff --git a/proton-c/src/tests/proactor.c b/proton-c/src/tests/proactor.c
index 49d753ae..95c6fbe0 100644
--- a/proton-c/src/tests/proactor.c
+++ b/proton-c/src/tests/proactor.c
@@ -729,7 +729,7 @@ static pn_event_type_t ssl_handler(test_handler_t *th, 
pn_event_t *e) {
}
 
case PN_CONNECTION_REMOTE_OPEN: {
- if (pn_connection_state(c) | PN_LOCAL_ACTIVE) {
+ if (pn_connection_state(c) & PN_LOCAL_ACTIVE) {
/* Outgoing connection is complete, close it */
pn_connection_close(c);
  } else {
{code}

Code 'C++ cast <...' is invalid C code. Use --std or --language to configure 
the language.
https://github.com/apache/qpid-proton/blob/b2e1acd97c4d66d0f62618aa715d408a0e01e3d1/proton-c/src/ssl/schannel.c#L981

Code 'namespacepn_experimental{' is invalid C code. Use --std or --language to 
configure the language.
https://github.com/apache/qpid-proton/blob/d3f92738ca28ba66c12fd1caa0707490e1911192/proton-c/src/proactor/win_iocp.c#L84

Memory leak: cc.work_queue_
https://github.com/apache/qpid-proton/blob/d3f92738ca28ba66c12fd1caa0707490e1911192/proton-c/bindings/cpp/src/proactor_container_impl.cpp#L188
https://github.com/apache/qpid-proton/blob/d3f92738ca28ba66c12fd1caa0707490e1911192/proton-c/bindings/cpp/src/proactor_container_impl.cpp#L507
(could not find where it is later freed)

%u in format string (no. 4) requires 'unsigned int' but the argument type is 
'signed char'
https://github.com/apache/qpid-proton/blob/d3f92738ca28ba66c12fd1caa0707490e1911192/proton-c/src/core/engine.c#L1628
(no idea how to print a C99 bool so that cppcheck is happy...)

Either the condition 'if(iocpd)' is redundant or there is possible null pointer 
dereference: iocpd
https://github.com/apache/qpid-proton/blob/d3f92738ca28ba66c12fd1caa0707490e1911192/proton-c/src/reactor/io/windows/iocp.c#L778

Possible null pointer dereference: result
https://github.com/apache/qpid-proton/blob/d3f92738ca28ba66c12fd1caa0707490e1911192/proton-c/src/reactor/io/windows/iocp.c#L253


> CppCheck 1.8 warnings
> -
>
> Key: PROTON-1572
> URL: https://issues.apache.org/jira/browse/PROTON-1572
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Michael Andre Pearce
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
> Attachments: cppcheck3.txt
>
>
> Using cppcheck 1.8 there are a number or warnings an errors detected.
> Attaching output of check run against master earlier today.



--
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] (PROTON-1571) The ssl C++ example appears leaky, proton::listener does not have a destructor

2017-09-05 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1571:
--

 Summary: The ssl C++ example appears leaky, proton::listener does 
not have a destructor
 Key: PROTON-1571
 URL: https://issues.apache.org/jira/browse/PROTON-1571
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding, examples
Affects Versions: proton-c-0.18.0
 Environment: commit e631bf6b11960d9687d42dfdde1ff4c65804981c 
(upstream/master)
Author: Andrew Stitcher 
Date:   Thu Aug 31 17:31:17 2017 -0400

PROTON-1567: Implement failover urls
- Example "reliable" client sending and receiving messages
- Also add jitter to retry backoff (with C++11
Reporter: Jiri Danek
Assignee: Cliff Jansen


After applying the following patch (to rin in a loop multiple times and to log 
RSS and VSS (the last two columns))

{code}
diff --git a/examples/cpp/ssl.cpp b/examples/cpp/ssl.cpp
index 99ceb4aa..f5864f42 100644
--- a/examples/cpp/ssl.cpp
+++ b/examples/cpp/ssl.cpp
@@ -37,6 +37,9 @@
 
 #include "fake_cpp11.hpp"
 
+#include 
+#include 
+
 using proton::connection_options;
 using proton::ssl_client_options;
 using proton::ssl_server_options;
@@ -178,8 +181,21 @@ int main(int argc, char **argv) {
 if (verify != verify_noname && verify != verify_full && verify != 
verify_fail)
 throw std::runtime_error("bad verify argument: " + verify);
 
-hello_world_direct hwd(address);
-proton::default_container(hwd).run();
+for (int i = 0; i < 1; i++) {
+try {
+hello_world_direct hwd(address);
+proton::default_container(hwd).run();
+} catch (const std::exception& e) {
+if (verify_failed) {
+if (verify == verify_fail) {
+std::cout << "Expected failure of connection with wrong 
peer name: " << e.what() << std::endl;
+}
+}
+}
+int ret = system("ps -eo pmem,comm,pid,maj_flt,min_flt,rss,vsz | grep 
ssl");
+(void)ret;
+// sleep(1);
+}
 return 0;
 } catch (const std::exception& e) {
 if (verify_failed) {
{code}

and normal compilation,

{{CFLAGS=-g cmake .. -DBUILD_GO=OFF -DENABLE_VALGRIND=OFF 
-DCMAKE_BUILD_TYPE=Release -GNijna}}

run the example and observe that with {{-v fail}}, the RSS grows, while without 
it, it seems to keep steady. This to me suggests that either the binding does 
not properly handle failures, or that the example itself does not.

{noformat}
$ examples/cpp/ssl -a amqps://localhost:46085/examples -c 
/home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs -v fail
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0378  6892  35928
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0475  7124  36344
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0572  7500  36756
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0669  7736  37160
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0773  7828  37444
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0874  8192  37860
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0972  8292  38272
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0   1074  8684  38664
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
 0.0 ssl 29657  0   1175  8776  38936
Expected failure of connection with wrong peer name: 
amqp:connection:framing-error: SSL Failure: error:14090086:SSL 

[jira] [Commented] (PROTON-1570) SASL auth with GSSAPI fails: amqp:connection:framing-error: AMQP header mismatch: AMQP SASL layer ['AMQP\x03\x01\x00\x00']

2017-09-04 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152902#comment-16152902
 ] 

Jiri Danek commented on PROTON-1570:


The following is printed in the broker log, when logging level for auth is set 
to DEBUG (per instructions in the skylla project)

{noformat}
21:50:53,391 DEBUG 
[org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoader] 
Initialized debug
21:50:53,392 DEBUG 
[org.apache.activemq.artemis.spi.core.security.jaas.Krb5LoginModule] abort
21:50:53,393 DEBUG 
[org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule] abort
21:50:53,393 DEBUG 
[org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager] 
Couldn't validate user: javax.security.auth.login.LoginException: 
java.lang.NullPointerException
at 
org.apache.activemq.artemis.spi.core.security.jaas.JaasCallbackHandler.handle(JaasCallbackHandler.java:73)
at 
javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:939)
at 
javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:936)
at java.security.AccessController.doPrivileged(Native Method)
at 
javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:936)
at 
org.apache.activemq.artemis.spi.core.security.jaas.Krb5LoginModule.login(Krb5LoginModule.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at 
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at 
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at 
org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager.getAuthenticatedSubject(ActiveMQJAASSecurityManager.java:186)
at 
org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager.validateUser(ActiveMQJAASSecurityManager.java:93)
at 
org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:130)
at 
org.apache.activemq.artemis.protocol.amqp.broker.AMQPConnectionCallback.isSupportsAnonymous(AMQPConnectionCallback.java:123)
at 
org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onAuthInit(AMQPConnectionContext.java:333)
at 
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatchAuth(ProtonHandler.java:333)
at 
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:213)
at 
org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:127)
at 
org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:141)
at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:642)
at 
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:236)
at 
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:494)
at 
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at 
org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:128)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 

[jira] [Created] (PROTON-1570) SASL auth with GSSAPI fails: amqp:connection:framing-error: AMQP header mismatch: AMQP SASL layer ['AMQP\x03\x01\x00\x00']

2017-09-04 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1570:
--

 Summary: SASL auth with GSSAPI fails: 
amqp:connection:framing-error: AMQP header mismatch: AMQP SASL layer 
['AMQP\x03\x01\x00\x00']
 Key: PROTON-1570
 URL: https://issues.apache.org/jira/browse/PROTON-1570
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.18.0
 Environment: commit e631bf6b11960d9687d42dfdde1ff4c65804981c 
(upstream/master)   

   
Author: Andrew Stitcher   


   
Date:   Thu Aug 31 17:31:17 2017 -0400  


   

PROTON-1567: Implement failover urls
- Example "reliable" client sending and receiving messages
- Also add jitter to retry backoff (with C++11)
Reporter: Jiri Danek
Assignee: Cliff Jansen


When using the sample client from 
https://github.com/ssorj/skylla/blob/master/cpp/connect.cpp to connect to 
current ActiveMQ Artemis server 2.4.0-SNAPSHOT, I am getting the following error

{noformat}
$ PN_TRACE_FRM=1 KRB5_TRACE=/dev/stdout LD_LIBRARY_PATH=/var/local/lib64/ 
./connect 127.0.0.1
[0x7b4c0550]:  -> AMQP
[0x7b4c0550]:0 -> @open(16) [container-id="", hostname="127.0.0.1", 
channel-max=32767]
[0x7b4c0550]:0 -> @close(24) [error=@error(29) 
[condition=:"amqp:connection:framing-error", description="AMQP header mismatch: 
AMQP SASL layer ['AMQP\x03\x01\x00\x00']"]]
[0x7b4c0550]:  <- EOS
[0x7b4c0550]:  -> EOS
terminate called after throwing an instance of 'proton::error'
  what():  amqp:connection:framing-error: AMQP header mismatch: AMQP SASL layer 
['AMQP\x03\x01\x00\x00']
Aborted
{noformat}

I am able to connect to the same server with Qpid JMS client without problems.



--
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] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)

2017-08-29 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16145338#comment-16145338
 ] 

Jiri Danek commented on QPIDJMS-314:


[~gemmellr] I've reported ARTEMIS-1376, if that is the exceptions you mean. It 
behaves the way you described, so I think so. It can be reproduced in Artemis 
OpenWire junittests.

> java.lang.AssertionError at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> -
>
> Key: QPIDJMS-314
> URL: https://issues.apache.org/jira/browse/QPIDJMS-314
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>Assignee: Robbie Gemmell
>
> I have a test suite which sometimes causes qpid-jms to die on AssertionError 
> from netty. Rerunning the single failing test does not seem to reproduce it, 
> I have to run the whole suite.
> First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
> docker image with the broker. Then run the test suite in a loop, until it 
> fails.
> {noformat}
> git clone g...@github.com:jdanekrh/cli-java.git
> cd cli-java/
> git checkout jd_code_push
> ret=0
> while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
> {noformat}
> Here is log from when it failed in Travis, 
> https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
> I do not know how to debug this (it never happened when I was running it 
> under debugger). Also, even if I could get it in a debugger, I would not know 
> what to do next.
> The relevant part of maven output is
> {noformat}
> [...]
> Receiving: 
> 6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
> 15:36:17.444Connecting: 1 0 1
> 15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
> 'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
> 'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
> None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
> 'reply_to': None, 'correlation_id': None, 'content_type': None, 
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
> 1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
> None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
> Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec 
> <<< FAILURE! - in AacMainTest
> sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
> FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Failed tests: 
>   AbstractMainTest.sendAndReceiveSingleMessage
> 

[jira] [Commented] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)

2017-08-28 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144727#comment-16144727
 ] 

Jiri Danek commented on QPIDJMS-314:


After removing SO_LINGER, the tests are now passing for me. The workaround 
works.

> java.lang.AssertionError at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> -
>
> Key: QPIDJMS-314
> URL: https://issues.apache.org/jira/browse/QPIDJMS-314
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>
> I have a test suite which sometimes causes qpid-jms to die on AssertionError 
> from netty. Rerunning the single failing test does not seem to reproduce it, 
> I have to run the whole suite.
> First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
> docker image with the broker. Then run the test suite in a loop, until it 
> fails.
> {noformat}
> git clone g...@github.com:jdanekrh/cli-java.git
> cd cli-java/
> git checkout jd_code_push
> ret=0
> while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
> {noformat}
> Here is log from when it failed in Travis, 
> https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
> I do not know how to debug this (it never happened when I was running it 
> under debugger). Also, even if I could get it in a debugger, I would not know 
> what to do next.
> The relevant part of maven output is
> {noformat}
> [...]
> Receiving: 
> 6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
> 15:36:17.444Connecting: 1 0 1
> 15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
> 'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
> 'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
> None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
> 'reply_to': None, 'correlation_id': None, 'content_type': None, 
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
> 1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
> None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
> Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec 
> <<< FAILURE! - in AacMainTest
> sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
> FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Failed tests: 
>   AbstractMainTest.sendAndReceiveSingleMessage
> sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 6: PASS
>   Run 7: 

[jira] [Updated] (PROTON-1559) Typo in some proactor examples

2017-08-28 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1559:
---
Description: 
Some proactor examples have a typo in the code that reads CLI options. It does 
not seem to have effect on functionality, because the {{argv[argc]}} element is 
always a NULL.

{code}
diff --git a/examples/c/proactor/direct.c b/examples/c/proactor/direct.c
index 15550e6b..d33010f0 100644
--- a/examples/c/proactor/direct.c
+++ b/examples/c/proactor/direct.c
@@ -308,8 +308,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
 
diff --git a/examples/c/proactor/receive.c b/examples/c/proactor/receive.c
index 6fd74a51..3f059f56 100644
--- a/examples/c/proactor/receive.c
+++ b/examples/c/proactor/receive.c
@@ -172,8 +172,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
 
diff --git a/examples/c/proactor/send.c b/examples/c/proactor/send.c
index 43da8b04..a80fbcb5 100644
--- a/examples/c/proactor/send.c
+++ b/examples/c/proactor/send.c
@@ -180,8 +180,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
{code}

  was:
Some proactor examples have a typo in the code that loads CLI options. It does 
not seem to have effect on functionality, because the {{argv[argc]}} element is 
always a NULL.

{code}
diff --git a/examples/c/proactor/direct.c b/examples/c/proactor/direct.c
index 15550e6b..d33010f0 100644
--- a/examples/c/proactor/direct.c
+++ b/examples/c/proactor/direct.c
@@ -308,8 +308,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
 
diff --git a/examples/c/proactor/receive.c b/examples/c/proactor/receive.c
index 6fd74a51..3f059f56 100644
--- a/examples/c/proactor/receive.c
+++ b/examples/c/proactor/receive.c
@@ -172,8 +172,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
 
diff --git a/examples/c/proactor/send.c b/examples/c/proactor/send.c
index 43da8b04..a80fbcb5 100644
--- a/examples/c/proactor/send.c
+++ b/examples/c/proactor/send.c
@@ -180,8 +180,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
{code}


> Typo in some proactor examples
> --
>
> Key: PROTON-1559
> URL: https://issues.apache.org/jira/browse/PROTON-1559
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Some proactor examples have a typo in the code that reads CLI options. It 
> does not seem to have effect on functionality, because the {{argv[argc]}} 
> element is always a NULL.
> {code}
> diff --git 

[jira] [Created] (PROTON-1559) Typo in some proactor examples

2017-08-28 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1559:
--

 Summary: Typo in some proactor examples
 Key: PROTON-1559
 URL: https://issues.apache.org/jira/browse/PROTON-1559
 Project: Qpid Proton
  Issue Type: Bug
  Components: examples, proton-c
Affects Versions: proton-c-0.18.0
Reporter: Jiri Danek
Priority: Minor


Some proactor examples have a typo in the code that loads CLI options. It does 
not seem to have effect on functionality, because the {{argv[argc]}} element is 
always a NULL.

{code}
diff --git a/examples/c/proactor/direct.c b/examples/c/proactor/direct.c
index 15550e6b..d33010f0 100644
--- a/examples/c/proactor/direct.c
+++ b/examples/c/proactor/direct.c
@@ -308,8 +308,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
 
diff --git a/examples/c/proactor/receive.c b/examples/c/proactor/receive.c
index 6fd74a51..3f059f56 100644
--- a/examples/c/proactor/receive.c
+++ b/examples/c/proactor/receive.c
@@ -172,8 +172,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
 
diff --git a/examples/c/proactor/send.c b/examples/c/proactor/send.c
index 43da8b04..a80fbcb5 100644
--- a/examples/c/proactor/send.c
+++ b/examples/c/proactor/send.c
@@ -180,8 +180,8 @@ int main(int argc, char **argv) {
   struct app_data_t app = {0};
   int i = 0;
   app.container_id = argv[i++];   /* Should be unique */
-  app.host = (argc > 1) ? argv[i++] : "";
-  app.port = (argc > 1) ? argv[i++] : "amqp";
+  app.host = (argc > i) ? argv[i++] : "";
+  app.port = (argc > i) ? argv[i++] : "amqp";
   app.amqp_address = (argc > i) ? argv[i++] : "examples";
   app.message_count = (argc > i) ? atoi(argv[i++]) : 10;
{code}



--
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] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable

2017-08-25 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1556:
---
Description: 
{{ssl_client_options}} probably cannot be self-assigned. See the attached 
report from clang-analyzer, which looks very plausible.

The problem is that assuming {{x == *this}}, the assignment operator will 
decref and then incref the same value. Assuming the reference count was {{1}} 
to start with, there will be use-after-free.

This probably does not matter that much in real-world code, but I found some 
quotations that making self assignment work is really important in C++...

{noformat}
58  ssl_domain& internal::ssl_domain::operator=(const ssl_domain) {
59  if (impl_) impl_->decref();
60  impl_ = x.impl_;
61  server_type_ = x.server_type_;
62  if (impl_) impl_->incref();
63  return *this;
64  }
{noformat}

I believe the static analyzer is correct, because when I do not make any 
changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors 
concerning the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get

{noformat}
$ valgrind ./ssl -c /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
==4950== Memcheck, a memory error detector
==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==4950== Command: ./ssl -c 
/home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
==4950== 
==4950== Invalid read of size 4
==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
==4950==by 0x4E715CC: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:62)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:59)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Block was alloc'd at
==4950==at 0x4C2C22F: operator new(unsigned long) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
(ssl_domain.cpp:72)
==4950==by 0x4E7195C: 
proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string const&, 
proton::ssl::verify_mode) (ssl_domain.cpp:120)
==4950==by 0x4032B9: main (ssl.cpp:175)
==4950== 
==4950== Invalid read of size 4
==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() 
(ssl_domain.cpp:66)
==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
==4950==by 0x4032F8: main (ssl.cpp:175)
==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:59)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Block was alloc'd at
==4950==at 0x4C2C22F: operator new(unsigned long) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
(ssl_domain.cpp:72)
==4950==by 0x4E7195C: 
proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string const&, 
proton::ssl::verify_mode) (ssl_domain.cpp:120)
==4950==by 0x4032B9: main (ssl.cpp:175)
==4950== 
==4950== Invalid read of size 8
==4950==at 0x4E71620: ~ssl_domain_impl (ssl_domain.cpp:36)
==4950==by 0x4E71620: decref (ssl_domain.cpp:40)
==4950==by 0x4E71620: proton::internal::ssl_domain::~ssl_domain() 
(ssl_domain.cpp:66)
==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
==4950==by 0x4032F8: main (ssl.cpp:175)
==4950==  Address 0x766a3c8 is 8 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 

[jira] [Updated] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable

2017-08-25 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1556:
---
Description: 
{{ssl_client_options}} probably cannot be self-assigned. See the attached 
report from clang-analyzer, which looks very plausible.

The problem is that assuming {{x == *this}}, the assignment operator will 
decref and then incref the same value. Assuming the reference count was {{1}} 
to start with, there will be use-after-free.

This probably does not matter that much in real-world code, but I found some 
quotations that making self assignment work is really important in C++...

{noformat}
58  ssl_domain& internal::ssl_domain::operator=(const ssl_domain) {
59  if (impl_) impl_->decref();
60  impl_ = x.impl_;
61  server_type_ = x.server_type_;
62  if (impl_) impl_->incref();
63  return *this;
64  }
{noformat}

I believe the static analyzer is correct, because when I do not make any 
changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors 
concerting the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get

{noformat}
$ valgrind ./ssl -c /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
==4950== Memcheck, a memory error detector
==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==4950== Command: ./ssl -c 
/home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
==4950== 
==4950== Invalid read of size 4
==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
==4950==by 0x4E715CC: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:62)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:59)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Block was alloc'd at
==4950==at 0x4C2C22F: operator new(unsigned long) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
(ssl_domain.cpp:72)
==4950==by 0x4E7195C: 
proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string const&, 
proton::ssl::verify_mode) (ssl_domain.cpp:120)
==4950==by 0x4032B9: main (ssl.cpp:175)
==4950== 
==4950== Invalid read of size 4
==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() 
(ssl_domain.cpp:66)
==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
==4950==by 0x4032F8: main (ssl.cpp:175)
==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:59)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Block was alloc'd at
==4950==at 0x4C2C22F: operator new(unsigned long) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
(ssl_domain.cpp:72)
==4950==by 0x4E7195C: 
proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string const&, 
proton::ssl::verify_mode) (ssl_domain.cpp:120)
==4950==by 0x4032B9: main (ssl.cpp:175)
==4950== 
==4950== Invalid read of size 8
==4950==at 0x4E71620: ~ssl_domain_impl (ssl_domain.cpp:36)
==4950==by 0x4E71620: decref (ssl_domain.cpp:40)
==4950==by 0x4E71620: proton::internal::ssl_domain::~ssl_domain() 
(ssl_domain.cpp:66)
==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
==4950==by 0x4032F8: main (ssl.cpp:175)
==4950==  Address 0x766a3c8 is 8 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 

[jira] [Created] (PROTON-1556) [proton=cpp] ssl_client_options is not self-assignable

2017-08-25 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1556:
--

 Summary: [proton=cpp] ssl_client_options is not self-assignable
 Key: PROTON-1556
 URL: https://issues.apache.org/jira/browse/PROTON-1556
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.18.0
Reporter: Jiri Danek
Assignee: Cliff Jansen
Priority: Trivial
 Attachments: report-7646dc.html

{{ssl_client_options}} probably cannot be self-assigned. See the attached 
report from clang-analyzer, which looks very plausible.

The problem is that assuming {{x == *this}}, the assignment operator will 
decref and then incref the same value. Assuming the reference count was {{1}} 
to start with, there will be use-after-free.

This probably does not matter that much in real-world code, but I found some 
quotations that making self assignment work is really important in C++...

{noformat}
58  ssl_domain& internal::ssl_domain::operator=(const ssl_domain) {
59  if (impl_) impl_->decref();
60  impl_ = x.impl_;
61  server_type_ = x.server_type_;
62  if (impl_) impl_->incref();
63  return *this;
64  }
{noformat}

I believe the static analyzer is correct, because when I do not make any 
changes to the {{examples/cpp/ssl}} example, valgrind does not report errors, 
but if I add a {{ssl_cli = ssl_cli;}}, then I get

{noformat}
$ valgrind ./ssl -c /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
==4950== Memcheck, a memory error detector
==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==4950== Command: ./ssl -c 
/home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
==4950== 
==4950== Invalid read of size 4
==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
==4950==by 0x4E715CC: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:62)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:59)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Block was alloc'd at
==4950==at 0x4C2C22F: operator new(unsigned long) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
(ssl_domain.cpp:72)
==4950==by 0x4E7195C: 
proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string const&, 
proton::ssl::verify_mode) (ssl_domain.cpp:120)
==4950==by 0x4032B9: main (ssl.cpp:175)
==4950== 
==4950== Invalid read of size 4
==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() 
(ssl_domain.cpp:66)
==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
==4950==by 0x4032F8: main (ssl.cpp:175)
==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator delete(void*) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
==4950==by 0x4E715FA: 
proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
(ssl_domain.cpp:59)
==4950==by 0x4032F0: operator= (ssl.hpp:172)
==4950==by 0x4032F0: main (ssl.cpp:176)
==4950==  Block was alloc'd at
==4950==at 0x4C2C22F: operator new(unsigned long) (in 
/nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
(ssl_domain.cpp:72)
==4950==by 0x4E7195C: 
proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string const&, 
proton::ssl::verify_mode) (ssl_domain.cpp:120)
==4950==by 0x4032B9: main (ssl.cpp:175)
==4950== 
==4950== Invalid read of size 8
==4950==at 0x4E71620: ~ssl_domain_impl (ssl_domain.cpp:36)
==4950==by 0x4E71620: decref (ssl_domain.cpp:40)
==4950==by 0x4E71620: proton::internal::ssl_domain::~ssl_domain() 
(ssl_domain.cpp:66)
==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
==4950==by 0x4032F8: main (ssl.cpp:175)
==4950==  Address 0x766a3c8 is 8 bytes inside a block of size 16 free'd
==4950==at 0x4C2D2EB: operator 

[jira] [Updated] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable

2017-08-25 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1556:
---
Summary: [proton-cpp] ssl_client_options is not self-assignable  (was: 
[proton=cpp] ssl_client_options is not self-assignable)

> [proton-cpp] ssl_client_options is not self-assignable
> --
>
> Key: PROTON-1556
> URL: https://issues.apache.org/jira/browse/PROTON-1556
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Danek
>Assignee: Cliff Jansen
>Priority: Trivial
> Attachments: report-7646dc.html
>
>
> {{ssl_client_options}} probably cannot be self-assigned. See the attached 
> report from clang-analyzer, which looks very plausible.
> The problem is that assuming {{x == *this}}, the assignment operator will 
> decref and then incref the same value. Assuming the reference count was {{1}} 
> to start with, there will be use-after-free.
> This probably does not matter that much in real-world code, but I found some 
> quotations that making self assignment work is really important in C++...
> {noformat}
> 58ssl_domain& internal::ssl_domain::operator=(const ssl_domain) {
> 59if (impl_) impl_->decref();
> 60impl_ = x.impl_;
> 61server_type_ = x.server_type_;
> 62if (impl_) impl_->incref();
> 63return *this;
> 64}
> {noformat}
> I believe the static analyzer is correct, because when I do not make any 
> changes to the {{examples/cpp/ssl}} example, valgrind does not report errors, 
> but if I add a {{ssl_cli = ssl_cli;}}, then I get
> {noformat}
> $ valgrind ./ssl -c 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950== Memcheck, a memory error detector
> ==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==4950== Command: ./ssl -c 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950== 
> ==4950== Invalid read of size 4
> ==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
> ==4950==by 0x4E715CC: 
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
> (ssl_domain.cpp:62)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA: 
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950==  Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsigned long) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
> (ssl_domain.cpp:72)
> ==4950==by 0x4E7195C: 
> proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, 
> proton::ssl::verify_mode) (ssl_domain.cpp:120)
> ==4950==by 0x4032B9: main (ssl.cpp:175)
> ==4950== 
> ==4950== Invalid read of size 4
> ==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
> ==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() 
> (ssl_domain.cpp:66)
> ==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
> ==4950==by 0x4032F8: main (ssl.cpp:175)
> ==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA: 
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950==  Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsigned long) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
> (ssl_domain.cpp:72)
> ==4950==by 0x4E7195C: 
> proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, 
> proton::ssl::verify_mode) (ssl_domain.cpp:120)
> ==4950==by 0x4032B9: main (ssl.cpp:175)
> 

[jira] [Created] (PROTON-1552) Epoll proactor example crash when given invalid hostname

2017-08-24 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1552:
--

 Summary: Epoll proactor example crash when given invalid hostname
 Key: PROTON-1552
 URL: https://issues.apache.org/jira/browse/PROTON-1552
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
 Environment: qpid-proton at commit

{noformat}
commit 1b1f3f9cae1c68545f93c74e017edae039875440 (upstream/master)
Author: Andrew Stitcher 
Date:   Mon Aug 14 14:38:26 2017 -0400

PROTON-1539: Ensure that SASL challenge and response frames generate a 
binary
- And never a null even if the binary is zero length
{noformat}
Reporter: Jiri Danek




{noformat}
[qpid-proton/build/examples/c/proactor]$ ./send upto.nogood.corp
PN_TRANSPORT_CLOSED: proton:io: Name or service not known - connect to  
upto.nogood.corp:5672   

epoll proactor failure in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:630: "arming 
polled file descriptor": No such file or directory  
   
Aborted
{noformat}

when compiled with libuv proactor, it does not crash

{noformat}
$ cmake -DPROACTOR=libuv -DBUILD_GO=OFF ..

[/qpid-proton/build_libuv]$ examples/c/proactor/send upto.nogood
PN_TRANSPORT_CLOSED: proton:io: unknown node or service - on connect resolving 
upto.nogood:5672
{noformat}

{noformat}
[jdanek@nixos:~/Work/repos/qpid-proton/build/examples/c/proactor]$ gdb --args 
./send upto.nogood.corp
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

[...]

(gdb) run
Starting program: 
/home/jdanek/Work/repos/qpid-proton/build/examples/c/proactor/send 
upto.nogood.corp
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".
PN_TRANSPORT_CLOSED: proton:io: Name or service not known - connect to  
upto.nogood.corp:5672
epoll proactor failure in 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:630: "arming 
polled file descriptor": No such file or directory

Program received signal SIGABRT, Aborted.
0x7740e384 in raise () from 
/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6
(gdb) bt
#0  0x7740e384 in raise () from 
/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6
#1  0x7740f7ea in abort () from 
/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6
#2  0x77bd45de in rearm (p=, ee=) at 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:630
#3  0x77bd5884 in pconnection_process (pc=0x6053c0, events=, timeout=, topup=) at 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1047
#4  0x77bd52c4 in pconnection_batch_next (batch=) at 
/home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:811
#5  0x00401b98 in run (app=0x7fffd100) at 
/home/jdanek/Work/repos/qpid-proton/examples/c/proactor/send.c:169
#6  0x00401ff3 in main (argc=, argv=) at 
/home/jdanek/Work/repos/qpid-proton/examples/c/proactor/send.c:192
{noformat}



--
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] [Resolved] (PROTON-1375) Compile without warnings under clang 4.0

2017-08-24 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek resolved PROTON-1375.

Resolution: Resolved

> Compile without warnings under clang 4.0
> 
>
> Key: PROTON-1375
> URL: https://issues.apache.org/jira/browse/PROTON-1375
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.16.0
> Environment: Debian Jessie. Install latest clang 4.0 snapshot from 
> http://apt.llvm.org/.
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> The following warnings prevent me from compiling proton-c with clang 4.0 
> snaphot
> # (/) /qpid-proton-fuzz/proton-c/src/tests/object.c:60:16: error: passing an 
> object that undergoes default argument promotion to 'va_start' has undefined 
> behavior
> # (x) 
> /test/qpid-proton/proton-c/bindings/cpp/include/proton/message.hpp:51:11: 
> error: instantiation of function
>   'proton::internal::cached_map proton::scalar>::cached_map' required here, but no definition is
> see complete error messages in comments below



--
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] (PROTON-1375) Compile without warnings under clang 4.0

2017-08-24 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated PROTON-1375:
---
Description: 
The following warnings prevent me from compiling proton-c with clang 4.0 snaphot

# (/) /qpid-proton-fuzz/proton-c/src/tests/object.c:60:16: error: passing an 
object that undergoes default argument promotion to 'va_start' has undefined 
behavior
# (/) /test/qpid-proton/proton-c/bindings/cpp/include/proton/message.hpp:51:11: 
error: instantiation of function
  'proton::internal::cached_map::cached_map' required here, but no definition is

see complete error messages in comments below

  was:
The following warnings prevent me from compiling proton-c with clang 4.0 snaphot

# (/) /qpid-proton-fuzz/proton-c/src/tests/object.c:60:16: error: passing an 
object that undergoes default argument promotion to 'va_start' has undefined 
behavior
# (x) /test/qpid-proton/proton-c/bindings/cpp/include/proton/message.hpp:51:11: 
error: instantiation of function
  'proton::internal::cached_map::cached_map' required here, but no definition is

see complete error messages in comments below


> Compile without warnings under clang 4.0
> 
>
> Key: PROTON-1375
> URL: https://issues.apache.org/jira/browse/PROTON-1375
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.16.0
> Environment: Debian Jessie. Install latest clang 4.0 snapshot from 
> http://apt.llvm.org/.
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> The following warnings prevent me from compiling proton-c with clang 4.0 
> snaphot
> # (/) /qpid-proton-fuzz/proton-c/src/tests/object.c:60:16: error: passing an 
> object that undergoes default argument promotion to 'va_start' has undefined 
> behavior
> # (/) 
> /test/qpid-proton/proton-c/bindings/cpp/include/proton/message.hpp:51:11: 
> error: instantiation of function
>   'proton::internal::cached_map proton::scalar>::cached_map' required here, but no definition is
> see complete error messages in comments below



--
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] (PROTON-1375) Compile without warnings under clang 4.0

2017-08-24 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139843#comment-16139843
 ] 

Jiri Danek commented on PROTON-1375:


The second problem was since removed in a commit related to PROTON-1288: c++ 
provide convenient access to message/filter maps. Compilation works for me, 
even with 6.0 snapshot. So I guess we are good on this front.

> Compile without warnings under clang 4.0
> 
>
> Key: PROTON-1375
> URL: https://issues.apache.org/jira/browse/PROTON-1375
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.16.0
> Environment: Debian Jessie. Install latest clang 4.0 snapshot from 
> http://apt.llvm.org/.
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> The following warnings prevent me from compiling proton-c with clang 4.0 
> snaphot
> # (/) /qpid-proton-fuzz/proton-c/src/tests/object.c:60:16: error: passing an 
> object that undergoes default argument promotion to 'va_start' has undefined 
> behavior
> # (x) 
> /test/qpid-proton/proton-c/bindings/cpp/include/proton/message.hpp:51:11: 
> error: instantiation of function
>   'proton::internal::cached_map proton::scalar>::cached_map' required here, but no definition is
> see complete error messages in comments below



--
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] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)

2017-08-22 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136824#comment-16136824
 ] 

Jiri Danek commented on QPIDJMS-314:


I'd be happy to promptly provide additional information if the reproduction 
steps I provided don't happen to work for you.

> java.lang.AssertionError at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> -
>
> Key: QPIDJMS-314
> URL: https://issues.apache.org/jira/browse/QPIDJMS-314
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>
> I have a test suite which sometimes causes qpid-jms to die on AssertionError 
> from netty. Rerunning the single failing test does not seem to reproduce it, 
> I have to run the whole suite.
> First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
> docker image with the broker. Then run the test suite in a loop, until it 
> fails.
> {noformat}
> git clone g...@github.com:jdanekrh/cli-java.git
> cd cli-java/
> git checkout jd_code_push
> ret=0
> while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
> {noformat}
> Here is log from when it failed in Travis, 
> https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
> I do not know how to debug this (it never happened when I was running it 
> under debugger). Also, even if I could get it in a debugger, I would not know 
> what to do next.
> The relevant part of maven output is
> {noformat}
> [...]
> Receiving: 
> 6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
> 15:36:17.444Connecting: 1 0 1
> 15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
> 'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
> 'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
> None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
> 'reply_to': None, 'correlation_id': None, 'content_type': None, 
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
> 1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
> None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
> Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec 
> <<< FAILURE! - in AacMainTest
> sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
> FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Failed tests: 
>   AbstractMainTest.sendAndReceiveSingleMessage
> sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 

[jira] [Updated] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)

2017-08-22 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated QPIDJMS-314:
---
Description: 
I have a test suite which sometimes causes qpid-jms to die on AssertionError 
from netty. Rerunning the single failing test does not seem to reproduce it, I 
have to run the whole suite.

First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
docker image with the broker. Then run the test suite in a loop, until it fails.

{noformat}
git clone g...@github.com:jdanekrh/cli-java.git
cd cli-java/
git checkout jd_code_push

ret=0
while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
{noformat}

Here is log from when it failed in Travis, 
https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207

I do not know how to debug this (it never happened when I was running it under 
debugger). Also, even if I could get it in a debugger, I would not know what to 
do next.

The relevant part of maven output is

{noformat}
[...]
Receiving: 
6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
15:36:17.444Connecting: 1 0 1
15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
'reply_to': None, 'correlation_id': None, 'content_type': None, 
'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec <<< 
FAILURE! - in AacMainTest
sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at 
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at 
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at 
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)

sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at 
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at 
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at 
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)


Results :

Failed tests: 
  AbstractMainTest.sendAndReceiveSingleMessage
sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: AbstractMainTest.sendAndReceiveWithAllSenderCLISwitches
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS


Tests run: 11, Failures: 2, Errors: 0, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] bom  SUCCESS [  0.002 s]
[INFO] parent . SUCCESS [  0.915 s]
[INFO] tests .. SUCCESS [  7.428 s]
[INFO] jmslib . SUCCESS [  0.038 s]
[INFO] cli-activemq ... SUCCESS [ 13.471 s]
[INFO] cli-artemis-jms  SUCCESS [ 10.811 s]
[INFO] 

[jira] [Created] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)

2017-08-22 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-314:
--

 Summary: java.lang.AssertionError at 
io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
 Key: QPIDJMS-314
 URL: https://issues.apache.org/jira/browse/QPIDJMS-314
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.24.0
Reporter: Jiri Danek


I have a test suite which sometimes causes qpid-jms to die on AssertionError 
from netty. Rerunning the single failing test does not seem to reproduce it, I 
have to run the whole suite.

First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
docker image with the broker. Then run the test suite in a loop, until it fails.

{noformat}
git clone g...@github.com:jdanekrh/cli-java.git
cd cli-java/
git checkout jd_code_push

ret=0
while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
{noformat}

Here is log from when it failed in Travis, 
https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207

I do not know how to debug this (it never happened when I was running it under 
debugger). Also, even if I could get it in a debugger, I would not know what to 
do next.

The relevant part of maven output is

{noformat}
[...]
Receiving: 
6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
15:36:17.444Connecting: 1 0 1
15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
'reply_to': None, 'correlation_id': None, 'content_type': None, 
'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec <<< 
FAILURE! - in AacMainTest
sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at 
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at 
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at 
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)

sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at 
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at 
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at 
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)


Results :

Failed tests: 
  AbstractMainTest.sendAndReceiveSingleMessage
sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: AbstractMainTest.sendAndReceiveWithAllSenderCLISwitches
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS


Tests run: 11, Failures: 2, Errors: 0, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] bom  SUCCESS [  0.002 s]
[INFO] parent . SUCCESS [  0.915 s]
[INFO] tests .. SUCCESS [  7.428 s]
[INFO] 

[jira] [Updated] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)

2017-08-22 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated QPIDJMS-314:
---
Description: 
I have a test suite which sometimes causes qpid-jms to die on AssertionError 
from netty. Rerunning the single failing test does not seem to reproduce it, I 
have to run the whole suite.

First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
docker image with the broker. Then run the test suite in a loop, until it fails.

{noformat}
git clone g...@github.com:jdanekrh/cli-java.git
cd cli-java/
git checkout jd_code_push

ret=0
while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
{noformat}

Here is log from when it failed in Travis, 
https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207

I do not know how to debug this (it never happened when I was running it under 
debugger). Also, even if I could get it in a debugger, I would not know what to 
do next.

The relevant part of maven output is

{noformat}
[...]
Receiving: 
6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
15:36:17.444Connecting: 1 0 1
15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
'reply_to': None, 'correlation_id': None, 'content_type': None, 
'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec <<< 
FAILURE! - in AacMainTest
sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at 
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at 
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at 
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)

sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at 
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at 
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at 
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)


Results :

Failed tests: 
  AbstractMainTest.sendAndReceiveSingleMessage
sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: AbstractMainTest.sendAndReceiveWithAllSenderCLISwitches
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS


Tests run: 11, Failures: 2, Errors: 0, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] bom  SUCCESS [  0.002 s]
[INFO] parent . SUCCESS [  0.915 s]
[INFO] tests .. SUCCESS [  7.428 s]
[INFO] jmslib . SUCCESS [  0.038 s]
[INFO] cli-activemq ... SUCCESS [ 13.471 s]
[INFO] cli-artemis-jms  SUCCESS [ 10.811 s]
[INFO] 

[jira] [Created] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-08-14 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1540:
--

 Summary: Add options to enable Sanitizers to CMake build
 Key: PROTON-1540
 URL: https://issues.apache.org/jira/browse/PROTON-1540
 Project: Qpid Proton
  Issue Type: Improvement
  Components: build
Reporter: Jiri Danek
Assignee: Jiri Danek
Priority: Minor


To get the most out of sanitizers in Qpid Dispatch, it helps to compile Proton 
with sanitizers as well.



--
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] (DISPATCH-809) Add options to enable Sanitizers to CMake build

2017-08-14 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-809:
---

 Summary: Add options to enable Sanitizers to CMake build
 Key: DISPATCH-809
 URL: https://issues.apache.org/jira/browse/DISPATCH-809
 Project: Qpid Dispatch
  Issue Type: Improvement
Affects Versions: 1.0.0
Reporter: Jiri Danek
Priority: Minor


The usage is to first enable sanitizers during compilation

{noformat}
cmake .. -DUSE_SANITIZERS=ON -DProton_DIR=... -DCMAKE_BUILD_TYPE=Release
{noformat}

or

{noformat}
cmake .. -DUSE_TSAN=ON -DProton_DIR=... -DCMAKE_BUILD_TYPE=Release
{noformat}

(TSan is incompatible with the other sanitizers.)

Then, either run unit tests with the usual {{ctest -VV}}, or run {{qdrouterd}}.

Sanitizers can be given parameters in environment variable. For example, 
{{TSAN_OPTIONS="color=always" ctest -VV}} to see colored error messages in 
ctest output. Other options are described on the Sanitizers website, e.g. 
https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags

For best results, also compile Proton with sanitizers.



--
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] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-10 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16113480#comment-16113480
 ] 

Jiri Danek edited comment on DISPATCH-782 at 8/10/17 1:57 PM:
--

[~ganeshmurthy] I tried reproducing on Fedora 25 in a VM (not docker) and I 
could not reproduce this. I then tried VM with Debian Stretch and I could 
reproduce it there with the usual

{noformat}
ret=0
while [[ $ret == 0 ]]; do rm -rf ~/.local/share/rr || true; /usr/bin/python 
"/main/qpid-dispatch/build/tests/run.py" "-x" "unit_tests" 
"/main/qpid-dispatch/tests/threads4.conf"; ret=$?; done;
{noformat}

edit: so it seems this is OS-dependent. I can reproduce it in a Debian VM or 
Docker, but not in Fedora VM or Docker.


was (Author: jdanek):
[~ganeshmurthy] I tried reproducing on Fedora 25 in a VM (not docker) and I 
could not reproduce this. I then tried VM with Debian Stretch and I could 
reproduce it there with the usual

{noformat}
ret=0
while [[ $ret == 0 ]]; do rm -rf ~/.local/share/rr || true; /usr/bin/python 
"/main/qpid-dispatch/build/tests/run.py" "-x" "unit_tests" 
"/main/qpid-dispatch/tests/threads4.conf"; ret=$?; done;
{noformat}

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> 

[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120144#comment-16120144
 ] 

Jiri Danek commented on QPIDJMS-313:


Agreed. I've reported that as ARTEMIS-1341.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120132#comment-16120132
 ] 

Jiri Danek commented on QPIDJMS-313:


Oh, I haven't read the whole document. Thanks.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek closed QPIDJMS-313.
--
Resolution: Invalid

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated QPIDJMS-313:
---
Affects Version/s: 0.24.0

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek reopened QPIDJMS-313:


> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120121#comment-16120121
 ] 

Jiri Danek commented on QPIDJMS-313:


Thanks for investigating. The difference between what I have and what the Qpid 
JMS test suite has is essentially this

{code}
diff --git 
a/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
 
b/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
index d56c533c..330f1208 100644
--- 
a/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
+++ 
b/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
@@ -968,8 +968,6 @@ public class JmsBytesMessageTest {
 public void testGetBodyThrowsMessageFormatException() throws JMSException {
 JmsBytesMessage bytesMessage = factory.createBytesMessage();
 bytesMessage.setStringProperty("property", "value");
-bytesMessage.writeByte((byte) 1);
-bytesMessage.writeInt(22);
 
 try {
 bytesMessage.getBody(StringBuffer.class);
{code}

If I remove the two lines (do not set any content of the message) then the Qpid 
JMS suite starts failing.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-313:
--

 Summary: Message#getBody does not throw when attempting to read a 
BytesMessage as String.class
 Key: QPIDJMS-313
 URL: https://issues.apache.org/jira/browse/QPIDJMS-313
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.23.0
Reporter: Jiri Danek
Priority: Minor


Consider the ActiveMQ Artemis test 
{{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
 adapted to run through multiple JMS ConnectionFactories in turn. This test 
passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.

{noformat}
 BytesMessage bytesMessage = sess.createBytesMessage();
 producer.send(bytesMessage);

 Message msg = cons.receiveNoWait();
 assertNotNull(msg);

 try {
msg.getBody(String.class);
fail("Exception expected");
 } catch (MessageFormatException e) {
 }
{noformat}

The failing line is the {{fail("Exception expected");}}, because qpid-jms does 
not throw {{MessageFormatException}} where it is supposed to.

According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
the message is a BytesMessage then this parameter must be set to byte[].class 
(or java.lang.Object.class). This method will reset the BytesMessage before and 
after use." ... "Throws: MessageFormatException" ... "if the message body 
cannot be assigned to the specified type."



--
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] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value

2017-08-09 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-312:
--

 Summary: Exception is not thrown when user attempts to create 
context with invalid session mode value
 Key: QPIDJMS-312
 URL: https://issues.apache.org/jira/browse/QPIDJMS-312
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.23.0
Reporter: Jiri Danek
Priority: Trivial


Consider Apache ActiveMQ Artemis tests 
{{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}}
 and {{#testInvalidSessionModesValue4}} (in the same class).

When it is adapted to run with multiple JMS clients, or when run from the 
standalone reproducer at 
https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java
(the standalone reproducer requires a running broker to connect to), the test 
passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 client) 
and fails on AMQP protocol (with qpid-jms-client as the JMS library):

{noformat}
   @Test(expected = JMSRuntimeException.class)
   public void testInvalidSessionModesValueMinusOne() {
  context.createContext(-1);
   }

   @Test(expected = JMSRuntimeException.class)
   public void testInvalidSessionModesValue4() {
  context.createContext(4);
   }
{noformat}

with exception

{noformat}
java.lang.AssertionError: Expected exception: javax.jms.JMSRuntimeException
{noformat}



--
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] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-03 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16113480#comment-16113480
 ] 

Jiri Danek commented on DISPATCH-782:
-

[~ganeshmurthy] I tried reproducing on Fedora 25 in a VM (not docker) and I 
could not reproduce this. I then tried VM with Debian Stretch and I could 
reproduce it there with the usual

{noformat}
ret=0
while [[ $ret == 0 ]]; do rm -rf ~/.local/share/rr || true; /usr/bin/python 
"/main/qpid-dispatch/build/tests/run.py" "-x" "unit_tests" 
"/main/qpid-dispatch/tests/threads4.conf"; ret=$?; done;
{noformat}

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.641383 + AGENT (debug) Add entity: 
> LogEntity(identity=log/MESSAGE, module=MESSAGE, name=log/MESSAGE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.642008 + AGENT (debug) Add entity: 
> ContainerEntity(containerName=----, 
> identity=container/----, 
> name=container/----, 
> type=org.apache.qpid.dispatch.container, workerThreads=4)
> 9: 2017-05-30 13:23:52.642676 + AGENT (debug) Add entity: 
> 

[jira] [Updated] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-782:

Attachment: (was: rr-4dd876.zip)

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.641383 + AGENT (debug) Add entity: 
> LogEntity(identity=log/MESSAGE, module=MESSAGE, name=log/MESSAGE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.642008 + AGENT (debug) Add entity: 
> ContainerEntity(containerName=----, 
> identity=container/----, 
> name=container/----, 
> type=org.apache.qpid.dispatch.container, workerThreads=4)
> 9: 2017-05-30 13:23:52.642676 + AGENT (debug) Add entity: 
> RouterEntity(allowUnsettledMulticast=False, area=0, helloInterval=1, 
> helloMaxAge=3, id=QDR, mobileAddrMaxAge=60, mode=standalone, raInterval=30, 
> raIntervalFlux=4, remoteLsMaxAge=60, saslConfigName=qdrouterd, 
> type=org.apache.qpid.dispatch.router, workerThreads=4)
> 9: 2017-05-30 13:23:52.643339 + SERVER (warning) HTTP support is not 
> available
> 9: 2017-05-30 13:23:52.643420 + SERVER (info) Container Name: QDR
> 9: 

[jira] [Updated] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-782:

Attachment: (was: rr.zip)

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.641383 + AGENT (debug) Add entity: 
> LogEntity(identity=log/MESSAGE, module=MESSAGE, name=log/MESSAGE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.642008 + AGENT (debug) Add entity: 
> ContainerEntity(containerName=----, 
> identity=container/----, 
> name=container/----, 
> type=org.apache.qpid.dispatch.container, workerThreads=4)
> 9: 2017-05-30 13:23:52.642676 + AGENT (debug) Add entity: 
> RouterEntity(allowUnsettledMulticast=False, area=0, helloInterval=1, 
> helloMaxAge=3, id=QDR, mobileAddrMaxAge=60, mode=standalone, raInterval=30, 
> raIntervalFlux=4, remoteLsMaxAge=60, saslConfigName=qdrouterd, 
> type=org.apache.qpid.dispatch.router, workerThreads=4)
> 9: 2017-05-30 13:23:52.643339 + SERVER (warning) HTTP support is not 
> available
> 9: 2017-05-30 13:23:52.643420 + SERVER (info) Container Name: QDR
> 9: 2017-05-30 

[jira] [Updated] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-801:

Description: 
My web browser can only connect to the server running the console and to the 
router; the computer does not have unrestricted network access. With this 
setup, the console does not work.

In stand-alone version, I am unable to even open the main page of the console. 
I get the following error in browser console

{noformat}
HTML1300: Navigation occurred.
File: stand-alone
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: dispatch_hawtio_console
SCRIPT5009: 'angular' is undefined
File: angular-patternfly.min.js, Line: 1, Column: 247
SCRIPT5009: 'angular' is undefined
File: dispatchPlugin.js, Line: 69, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverview.js, Line: 37, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverviewLogsController.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: navbar.js, Line: 86, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrList.js, Line: 31, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrListChart.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrCharts.js, Line: 29, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrSchema.js, Line: 24, Column: 3
...
{noformat}

In Google Chrome, same thing happens

{noformat}
192.168.99.1/:29 GET https://fonts.googleapis.com/css?family=Open+Sans 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:36 GET 
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:38 GET 
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:136 GET 
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:40 GET 
https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/css/patternfly.min.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:41 GET 
https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/css/patternfly-additions.min.css
 net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:45 GET 
https://cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:46 GET 
https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:105 GET 
https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:110 GET 
https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/js/patternfly.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:113 GET 
https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:114 GET 
https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular-route.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:36 GET 
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:38 GET 
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:115 GET 
https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.6.2/angular-resource.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:117 GET 
https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/0.14.3/ui-bootstrap.min.js
 net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:118 GET 
https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/0.14.3/ui-bootstrap-tpls.min.js
 net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:121 GET 
https://cdnjs.cloudflare.com/ajax/libs/angular-sanitize/1.5.11/angular-sanitize.min.js
 net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:127 GET 
https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.14/d3.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:128 GET 
https://cdnjs.cloudflare.com/ajax/libs/d3-queue/3.0.3/d3-queue.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:135 GET 
https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:137 GET 
https://cdnjs.cloudflare.com/ajax/libs/notify/0.4.2/notify.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:31 GET 
https://code.jquery.com/ui/1.11.4/themes/smoothness/jquery-ui.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:106 GET https://code.jquery.com/ui/1.11.4/jquery-ui.min.js 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:47 GET 
https://cdn.rawgit.com/mar10/dynatree/master/dist/skin/ui.dynatree.css 
net::ERR_NAME_NOT_RESOLVED
192.168.99.1/:52 GET 

[jira] [Updated] (DISPATCH-800) Hawtio version of the console is unable to connect to a router when running offline

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-800:

Priority: Minor  (was: Major)

> Hawtio version of the console is unable to connect to a router when running 
> offline
> ---
>
> Key: DISPATCH-800
> URL: https://issues.apache.org/jira/browse/DISPATCH-800
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>Priority: Minor
>
> My web browser can only connect to the server running the console and to the 
> router; the computer does not have unrestricted network access. With this 
> setup, the console does not work.
> In Hawtio version of the console running on IE11, I am unable to login. After 
> filling in the router ip and port, I see the rotating wheel of dots forever. 
> After a while, the following errors appear in browser console
> {noformat}
> HTML1300: Navigation occurred.
> File: hawtio
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: list
> [QDR] *creating Dispatch Console
> [QDR] curPath is /
> [RBAC] Using mbean  
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
> client-side role based access control
> [Core] hawtio started
> XML5632: Only one root element is allowed.
> Line: 3, Column 2
> [QDR] testConnect called with reconnect true using ws protocol
> [QDR] got schema after connection
> [QDR] requesting a topology
> SCRIPT438: Object doesn't support property or method 'queue'
> File: eval code (40), Line: 5, Column: 8603
> [Window] Object doesn't support property or method 'queue'  ( href=":5">:5:8603)
> {noformat}
> In Chrome, the symptoms and the error is essentially the same:
> {noformat}
> app.js?c8641b2e13788127:4 [Deprecation] Synchronous XMLHttpRequest on the 
> main thread is deprecated because of its detrimental effects to the end 
> user's experience. For more help, check https://xhr.spec.whatwg.org/.
> send @ app.js?c8641b2e13788127:4
> d3.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> d3-queue.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> FileSaver.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> app.js?c8641b2e13788127:16 [Themes] unknown theme name, using default theme
> app.js?c8641b2e13788127:16 [QDR] *creating Dispatch 
> Console
> app.js?c8641b2e13788127:16 [QDR] curPath is /
> cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css Failed to 
> load resource: net::ERR_NAME_NOT_RESOLVED
> maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css Failed to 
> load resource: net::ERR_NAME_NOT_RESOLVED
> app.js?c8641b2e13788127:16 [RBAC] Using mbean  
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
> client-side role based access control
> app.js?c8641b2e13788127:16 [Core] hawtio started
> jquery.tipsy.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> tooltipsy.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> code.jquery.com/ui/1.8.24/themes/base/jquery-ui.css Failed to load resource: 
> net::ERR_NAME_NOT_RESOLVED
> app.js?c8641b2e13788127:16 [QDR] testConnect called with reconnect true using 
> ws protocol
> app.js?c8641b2e13788127:16 [QDR] got schema after connection
> app.js?c8641b2e13788127:16 [QDR] requesting a topology
> app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: QDR.queue is not a 
> function  ( href="http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5;>http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5:8603)
> consoleLogger @ app.js?c8641b2e13788127:16
> {noformat}
> CC [~eallen]



--
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] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-801:

Priority: Minor  (was: Major)

> Stand-alone version of the console on IE11 does not open at all
> ---
>
> Key: DISPATCH-801
> URL: https://issues.apache.org/jira/browse/DISPATCH-801
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>Priority: Minor
>
> My web browser can only connect to the server running the console and to the 
> router; the computer does not have unrestricted network access. With this 
> setup, the console does not work.
> In stand-alone version, I am unable to even open the main page of the 
> console. I get the following error in browser console
> {noformat}
> HTML1300: Navigation occurred.
> File: stand-alone
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: dispatch_hawtio_console
> SCRIPT5009: 'angular' is undefined
> File: angular-patternfly.min.js, Line: 1, Column: 247
> SCRIPT5009: 'angular' is undefined
> File: dispatchPlugin.js, Line: 69, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverview.js, Line: 37, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverviewLogsController.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: navbar.js, Line: 86, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrList.js, Line: 31, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrListChart.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrCharts.js, Line: 29, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrSchema.js, Line: 24, Column: 3
> ...
> {noformat}
> In Google Chrome, same thing happens
> {noformat}
> 192.168.99.1/:29 GET https://fonts.googleapis.com/css?family=Open+Sans 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:36 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:38 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:136 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:40 GET 
> https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/css/patternfly.min.css
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:41 GET 
> https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/css/patternfly-additions.min.css
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:45 GET 
> https://cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:46 GET 
> https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:105 GET 
> https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:110 GET 
> https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/js/patternfly.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:113 GET 
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:114 GET 
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular-route.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:36 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:38 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:115 GET 
> https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.6.2/angular-resource.min.js
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:117 GET 
> https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/0.14.3/ui-bootstrap.min.js
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:118 GET 
> https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/0.14.3/ui-bootstrap-tpls.min.js
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:121 GET 
> 

[jira] [Updated] (DISPATCH-801) Stand-alone version of the console does not open at all when running offline

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-801:

Summary: Stand-alone version of the console does not open at all when 
running offline  (was: Stand-alone version of the console on IE11 does not open 
at all)

> Stand-alone version of the console does not open at all when running offline
> 
>
> Key: DISPATCH-801
> URL: https://issues.apache.org/jira/browse/DISPATCH-801
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>Priority: Minor
>
> My web browser can only connect to the server running the console and to the 
> router; the computer does not have unrestricted network access. With this 
> setup, the console does not work.
> In stand-alone version, I am unable to even open the main page of the 
> console. I get the following error in browser console
> {noformat}
> HTML1300: Navigation occurred.
> File: stand-alone
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: dispatch_hawtio_console
> SCRIPT5009: 'angular' is undefined
> File: angular-patternfly.min.js, Line: 1, Column: 247
> SCRIPT5009: 'angular' is undefined
> File: dispatchPlugin.js, Line: 69, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverview.js, Line: 37, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverviewLogsController.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: navbar.js, Line: 86, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrList.js, Line: 31, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrListChart.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrCharts.js, Line: 29, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrSchema.js, Line: 24, Column: 3
> ...
> {noformat}
> In Google Chrome, same thing happens
> {noformat}
> 192.168.99.1/:29 GET https://fonts.googleapis.com/css?family=Open+Sans 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:36 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:38 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:136 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:40 GET 
> https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/css/patternfly.min.css
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:41 GET 
> https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/css/patternfly-additions.min.css
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:45 GET 
> https://cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:46 GET 
> https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:105 GET 
> https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:110 GET 
> https://cdnjs.cloudflare.com/ajax/libs/patternfly/3.22.1/js/patternfly.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:113 GET 
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:114 GET 
> https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular-route.min.js 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:36 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:38 GET 
> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css 
> net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:115 GET 
> https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.6.2/angular-resource.min.js
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:117 GET 
> https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/0.14.3/ui-bootstrap.min.js
>  net::ERR_NAME_NOT_RESOLVED
> 192.168.99.1/:118 GET 
> 

[jira] [Updated] (DISPATCH-800) Hawtio version of the console is unable to connect to a router when running offline

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-800:

Description: 
My web browser can only connect to the server running the console and to the 
router; the computer does not have unrestricted network access. With this 
setup, the console does not work.

In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

{noformat}
HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)
{noformat}

In Chrome, the symptoms and the error is essentially the same:

{noformat}
app.js?c8641b2e13788127:4 [Deprecation] Synchronous XMLHttpRequest on the main 
thread is deprecated because of its detrimental effects to the end user's 
experience. For more help, check https://xhr.spec.whatwg.org/.
send @ app.js?c8641b2e13788127:4
d3.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
d3-queue.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
FileSaver.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [Themes] unknown theme name, using default theme
app.js?c8641b2e13788127:16 [QDR] *creating Dispatch 
Console
app.js?c8641b2e13788127:16 [QDR] curPath is /
cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css Failed to 
load resource: net::ERR_NAME_NOT_RESOLVED
maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css Failed to 
load resource: net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
app.js?c8641b2e13788127:16 [Core] hawtio started
jquery.tipsy.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
tooltipsy.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
code.jquery.com/ui/1.8.24/themes/base/jquery-ui.css Failed to load resource: 
net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [QDR] testConnect called with reconnect true using 
ws protocol
app.js?c8641b2e13788127:16 [QDR] got schema after connection
app.js?c8641b2e13788127:16 [QDR] requesting a topology
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: QDR.queue is not a 
function  (http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5;>http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5:8603)
consoleLogger @ app.js?c8641b2e13788127:16
{noformat}
CC [~eallen]

  was:
In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

{noformat}
HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)
{noformat}

In Chrome, the symptoms and the error is essentially the same:

{noformat}
app.js?c8641b2e13788127:4 [Deprecation] Synchronous XMLHttpRequest on the main 
thread is deprecated because of its detrimental effects to the end user's 
experience. For more help, check https://xhr.spec.whatwg.org/.
send @ app.js?c8641b2e13788127:4
d3.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
d3-queue.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
FileSaver.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [Themes] unknown theme name, using default theme
app.js?c8641b2e13788127:16 

[jira] [Updated] (DISPATCH-800) Hawtio version of the console is unable to connect to a router when running offline

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-800:

Summary: Hawtio version of the console is unable to connect to a router 
when running offline  (was: Hawtio version of the console on IE11 is unable to 
connect to a router)

> Hawtio version of the console is unable to connect to a router when running 
> offline
> ---
>
> Key: DISPATCH-800
> URL: https://issues.apache.org/jira/browse/DISPATCH-800
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In Hawtio version of the console running on IE11, I am unable to login. After 
> filling in the router ip and port, I see the rotating wheel of dots forever. 
> After a while, the following errors appear in browser console
> {noformat}
> HTML1300: Navigation occurred.
> File: hawtio
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: list
> [QDR] *creating Dispatch Console
> [QDR] curPath is /
> [RBAC] Using mbean  
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
> client-side role based access control
> [Core] hawtio started
> XML5632: Only one root element is allowed.
> Line: 3, Column 2
> [QDR] testConnect called with reconnect true using ws protocol
> [QDR] got schema after connection
> [QDR] requesting a topology
> SCRIPT438: Object doesn't support property or method 'queue'
> File: eval code (40), Line: 5, Column: 8603
> [Window] Object doesn't support property or method 'queue'  ( href=":5">:5:8603)
> {noformat}
> In Chrome, the symptoms and the error is essentially the same:
> {noformat}
> app.js?c8641b2e13788127:4 [Deprecation] Synchronous XMLHttpRequest on the 
> main thread is deprecated because of its detrimental effects to the end 
> user's experience. For more help, check https://xhr.spec.whatwg.org/.
> send @ app.js?c8641b2e13788127:4
> d3.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> d3-queue.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> FileSaver.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> app.js?c8641b2e13788127:16 [Themes] unknown theme name, using default theme
> app.js?c8641b2e13788127:16 [QDR] *creating Dispatch 
> Console
> app.js?c8641b2e13788127:16 [QDR] curPath is /
> cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css Failed to 
> load resource: net::ERR_NAME_NOT_RESOLVED
> maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css Failed to 
> load resource: net::ERR_NAME_NOT_RESOLVED
> app.js?c8641b2e13788127:16 [RBAC] Using mbean  
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
> client-side role based access control
> app.js?c8641b2e13788127:16 [Core] hawtio started
> jquery.tipsy.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> tooltipsy.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
> code.jquery.com/ui/1.8.24/themes/base/jquery-ui.css Failed to load resource: 
> net::ERR_NAME_NOT_RESOLVED
> app.js?c8641b2e13788127:16 [QDR] testConnect called with reconnect true using 
> ws protocol
> app.js?c8641b2e13788127:16 [QDR] got schema after connection
> app.js?c8641b2e13788127:16 [QDR] requesting a topology
> app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: QDR.queue is not a 
> function  ( href="http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5;>http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5:8603)
> consoleLogger @ app.js?c8641b2e13788127:16
> {noformat}
> CC [~eallen]



--
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] (DISPATCH-800) Hawtio version of the console on IE11 is unable to connect to a router

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-800:

Description: 
In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

{noformat}
HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)
{noformat}

In Chrome, the symptoms and the error is essentially the same:

{noformat}
app.js?c8641b2e13788127:4 [Deprecation] Synchronous XMLHttpRequest on the main 
thread is deprecated because of its detrimental effects to the end user's 
experience. For more help, check https://xhr.spec.whatwg.org/.
send @ app.js?c8641b2e13788127:4
d3.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
d3-queue.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
FileSaver.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [Themes] unknown theme name, using default theme
app.js?c8641b2e13788127:16 [QDR] *creating Dispatch 
Console
app.js?c8641b2e13788127:16 [QDR] curPath is /
cdnjs.cloudflare.com/ajax/libs/jquery.tipsy/1.0.2/jquery.tipsy.css Failed to 
load resource: net::ERR_NAME_NOT_RESOLVED
maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css Failed to 
load resource: net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
app.js?c8641b2e13788127:16 [Core] hawtio started
jquery.tipsy.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
tooltipsy.min.js Failed to load resource: net::ERR_NAME_NOT_RESOLVED
code.jquery.com/ui/1.8.24/themes/base/jquery-ui.css Failed to load resource: 
net::ERR_NAME_NOT_RESOLVED
app.js?c8641b2e13788127:16 [QDR] testConnect called with reconnect true using 
ws protocol
app.js?c8641b2e13788127:16 [QDR] got schema after connection
app.js?c8641b2e13788127:16 [QDR] requesting a topology
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: QDR.queue is not a 
function  (http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5;>http://192.168.99.1:8080/hawtio/dispatch_hawtio_console/:5:8603)
consoleLogger @ app.js?c8641b2e13788127:16
{noformat}
CC [~eallen]

  was:
In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)

CC [~eallen]


> Hawtio version of the console on IE11 is unable to connect to a router
> --
>
> Key: DISPATCH-800
> URL: https://issues.apache.org/jira/browse/DISPATCH-800
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In Hawtio version of the console running on IE11, I am unable to 

[jira] [Updated] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-801:

Description: 
In stand-alone version, I am unable to even open the main page of the console. 
I get the following error in browser console


HTML1300: Navigation occurred.
File: stand-alone
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: dispatch_hawtio_console
SCRIPT5009: 'angular' is undefined
File: angular-patternfly.min.js, Line: 1, Column: 247
SCRIPT5009: 'angular' is undefined
File: dispatchPlugin.js, Line: 69, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverview.js, Line: 37, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverviewLogsController.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: navbar.js, Line: 86, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrList.js, Line: 31, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrListChart.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrCharts.js, Line: 29, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrSchema.js, Line: 24, Column: 3
...

CC [~eallen]

  was:
In stand-alone version, I am unable to even open the main page of the console. 
I get the following error in browser console

HTML1300: Navigation occurred.
File: stand-alone
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: dispatch_hawtio_console
SCRIPT5009: 'angular' is undefined
File: angular-patternfly.min.js, Line: 1, Column: 247
SCRIPT5009: 'angular' is undefined
File: dispatchPlugin.js, Line: 69, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverview.js, Line: 37, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverviewLogsController.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: navbar.js, Line: 86, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrList.js, Line: 31, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrListChart.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrCharts.js, Line: 29, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrSchema.js, Line: 24, Column: 3
...

CC [~eallen]


> Stand-alone version of the console on IE11 does not open at all
> ---
>
> Key: DISPATCH-801
> URL: https://issues.apache.org/jira/browse/DISPATCH-801
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In stand-alone version, I am unable to even open the main page of the 
> console. I get the following error in browser console
> HTML1300: Navigation occurred.
> File: stand-alone
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: dispatch_hawtio_console
> SCRIPT5009: 'angular' is undefined
> File: angular-patternfly.min.js, Line: 1, Column: 247
> SCRIPT5009: 'angular' is undefined
> File: dispatchPlugin.js, Line: 69, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverview.js, Line: 37, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverviewLogsController.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: navbar.js, Line: 86, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrList.js, Line: 31, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrListChart.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrCharts.js, 

[jira] [Commented] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112376#comment-16112376
 ] 

Jiri Danek commented on DISPATCH-801:
-

The issue is actually something else. The console does not work when the 
browser does not have access to the Internet (it can only connect to the server 
running the console and to the router; it does not have unrestricted network 
access).

I will edit the ticket to describe the real cause.

> Stand-alone version of the console on IE11 does not open at all
> ---
>
> Key: DISPATCH-801
> URL: https://issues.apache.org/jira/browse/DISPATCH-801
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In stand-alone version, I am unable to even open the main page of the 
> console. I get the following error in browser console
> HTML1300: Navigation occurred.
> File: stand-alone
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: dispatch_hawtio_console
> SCRIPT5009: 'angular' is undefined
> File: angular-patternfly.min.js, Line: 1, Column: 247
> SCRIPT5009: 'angular' is undefined
> File: dispatchPlugin.js, Line: 69, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverview.js, Line: 37, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverviewLogsController.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: navbar.js, Line: 86, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrList.js, Line: 31, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrListChart.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrCharts.js, Line: 29, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrSchema.js, Line: 24, Column: 3
> ...
> CC [~eallen]



--
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] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-801:

Environment: 
Tested in Internet Explorer 11 on Windows 7 with git tip at
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}

  was:
Tested with git tip at
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}


> Stand-alone version of the console on IE11 does not open at all
> ---
>
> Key: DISPATCH-801
> URL: https://issues.apache.org/jira/browse/DISPATCH-801
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In stand-alone version, I am unable to even open the main page of the 
> console. I get the following error in browser console
> HTML1300: Navigation occurred.
> File: stand-alone
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: dispatch_hawtio_console
> SCRIPT5009: 'angular' is undefined
> File: angular-patternfly.min.js, Line: 1, Column: 247
> SCRIPT5009: 'angular' is undefined
> File: dispatchPlugin.js, Line: 69, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverview.js, Line: 37, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverviewLogsController.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: navbar.js, Line: 86, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrList.js, Line: 31, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrListChart.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrCharts.js, Line: 29, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrSchema.js, Line: 24, Column: 3
> ...
> CC [~eallen]



--
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] (DISPATCH-800) Hawtio version of the console on IE11 is unable to connect to a router

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-800:

Environment: 
Tested in Internet Explorer 11 on Windows 7 with git tip at
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}

  was:
Tested with git tip at
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}


> Hawtio version of the console on IE11 is unable to connect to a router
> --
>
> Key: DISPATCH-800
> URL: https://issues.apache.org/jira/browse/DISPATCH-800
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested in Internet Explorer 11 on Windows 7 with git tip 
> at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In Hawtio version of the console running on IE11, I am unable to login. After 
> filling in the router ip and port, I see the rotating wheel of dots forever. 
> After a while, the following errors appear in browser console
> HTML1300: Navigation occurred.
> File: hawtio
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: list
> [QDR] *creating Dispatch Console
> [QDR] curPath is /
> [RBAC] Using mbean  
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
> client-side role based access control
> [Core] hawtio started
> XML5632: Only one root element is allowed.
> Line: 3, Column 2
> [QDR] testConnect called with reconnect true using ws protocol
> [QDR] got schema after connection
> [QDR] requesting a topology
> SCRIPT438: Object doesn't support property or method 'queue'
> File: eval code (40), Line: 5, Column: 8603
> [Window] Object doesn't support property or method 'queue'  ( href=":5">:5:8603)
> CC [~eallen]



--
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] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-801:

Description: 
In stand-alone version, I am unable to even open the main page of the console. 
I get the following error in browser console

HTML1300: Navigation occurred.
File: stand-alone
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: dispatch_hawtio_console
SCRIPT5009: 'angular' is undefined
File: angular-patternfly.min.js, Line: 1, Column: 247
SCRIPT5009: 'angular' is undefined
File: dispatchPlugin.js, Line: 69, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverview.js, Line: 37, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrOverviewLogsController.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: navbar.js, Line: 86, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrList.js, Line: 31, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrListChart.js, Line: 24, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrCharts.js, Line: 29, Column: 3
SCRIPT5007: Unable to get property 'controller' of undefined or null reference
File: qdrSchema.js, Line: 24, Column: 3
...

CC [~eallen]

  was:
In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)

CC [~eallen]


> Stand-alone version of the console on IE11 does not open at all
> ---
>
> Key: DISPATCH-801
> URL: https://issues.apache.org/jira/browse/DISPATCH-801
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Tested with git tip at
> {noformat}
> commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
> Author: Ganesh Murthy 
> Date:   Mon Jul 31 17:09:30 2017 -0400
> DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
> correctly
> {noformat}
>Reporter: Jiri Danek
>
> In stand-alone version, I am unable to even open the main page of the 
> console. I get the following error in browser console
> HTML1300: Navigation occurred.
> File: stand-alone
> DOM7011: The code on this page disabled back and forward caching. For more 
> information, see: http://go.microsoft.com/fwlink/?LinkID=291337
> File: dispatch_hawtio_console
> SCRIPT5009: 'angular' is undefined
> File: angular-patternfly.min.js, Line: 1, Column: 247
> SCRIPT5009: 'angular' is undefined
> File: dispatchPlugin.js, Line: 69, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverview.js, Line: 37, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrOverviewLogsController.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: navbar.js, Line: 86, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrList.js, Line: 31, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrListChart.js, Line: 24, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrCharts.js, Line: 29, Column: 3
> SCRIPT5007: Unable to get property 'controller' of undefined or null reference
> File: qdrSchema.js, Line: 24, Column: 3
> ...
> CC [~eallen]



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

[jira] [Created] (DISPATCH-801) Stand-alone version of the console on IE11 does not open at all

2017-08-03 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-801:
---

 Summary: Stand-alone version of the console on IE11 does not open 
at all
 Key: DISPATCH-801
 URL: https://issues.apache.org/jira/browse/DISPATCH-801
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Tested with git tip at
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}
Reporter: Jiri Danek


In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)

CC [~eallen]



--
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] (DISPATCH-800) Hawtio version of the console on IE11 is unable to connect to a router

2017-08-03 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-800:
---

 Summary: Hawtio version of the console on IE11 is unable to 
connect to a router
 Key: DISPATCH-800
 URL: https://issues.apache.org/jira/browse/DISPATCH-800
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Tested with git tip at
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}
Reporter: Jiri Danek


In Hawtio version of the console running on IE11, I am unable to login. After 
filling in the router ip and port, I see the rotating wheel of dots forever. 
After a while, the following errors appear in browser console

HTML1300: Navigation occurred.
File: hawtio
DOM7011: The code on this page disabled back and forward caching. For more 
information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: list
[QDR] *creating Dispatch Console
[QDR] curPath is /
[RBAC] Using mbean  
hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity  for 
client-side role based access control
[Core] hawtio started
XML5632: Only one root element is allowed.
Line: 3, Column 2
[QDR] testConnect called with reconnect true using ws protocol
[QDR] got schema after connection
[QDR] requesting a topology
SCRIPT438: Object doesn't support property or method 'queue'
File: eval code (40), Line: 5, Column: 8603
[Window] Object doesn't support property or method 'queue'  (:5:8603)

CC [~eallen]



--
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] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-02 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111449#comment-16111449
 ] 

Jiri Danek edited comment on DISPATCH-782 at 8/2/17 6:16 PM:
-

Sorry for the problems with the trace. I did the rr recording wrong. For some 
reason, the command above does not work. Maybe because of the way the run.py 
script executes the test (execvp or some python magic on python 2.7).

I had to do

{noformat}
$ ./run.py --sh > script.sh
$ cat > my_test 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/root/.local/share/rr/latest-trace/mmap_hardlink_69_unit_tests...done.
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
>>> >>> >>> >>> ... ... >>> ... ... >>> ... ... ... 
>>> 
Remote debugging using :9

--
 ---> Reached target process 4819 at event 506.
--
warning: unable to open /proc file '/proc/4819/task/4819/maps'
warning: remote target does not support file transfer, attempting to access 
files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/40/6841a557b6674c3e8bf7c8c6be4d23183b6088.debug...done.
done.
0x7fca4b8a0c20 in _start () from /lib64/ld-linux-x86-64.so.2
(rr) c
Continuing.
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/rr/librrpreload.so changed: replay 
divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/rr/librrpreload.so changed: replay 
divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /main/qpid-dispatch/build/src/libqpid-dispatch.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /main/qpid-dispatch/build/src/libqpid-dispatch.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-core.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-core.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-proactor.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-proactor.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libpthread-2.24.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libpthread-2.24.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/librt-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/librt-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libdl-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libdl-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR 

[jira] [Commented] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-02 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111449#comment-16111449
 ] 

Jiri Danek commented on DISPATCH-782:
-

Sorry for the problems with the trace. I did the rr recording wrong. For some 
reason, the command above does not work. Maybe because of the way the run.py 
script executes the test (execvp or some python magic on python 2.7).

I had to do

{noformat}
$ ./run.py --sh > script.sh
$ cat > my_test 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/root/.local/share/rr/latest-trace/mmap_hardlink_69_unit_tests...done.
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
>>> >>> >>> >>> ... ... >>> ... ... >>> ... ... ... 
>>> 
Remote debugging using :9

--
 ---> Reached target process 4819 at event 506.
--
warning: unable to open /proc file '/proc/4819/task/4819/maps'
warning: remote target does not support file transfer, attempting to access 
files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/40/6841a557b6674c3e8bf7c8c6be4d23183b6088.debug...done.
done.
0x7fca4b8a0c20 in _start () from /lib64/ld-linux-x86-64.so.2
(rr) c
Continuing.
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/rr/librrpreload.so changed: replay 
divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/rr/librrpreload.so changed: replay 
divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /main/qpid-dispatch/build/src/libqpid-dispatch.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /main/qpid-dispatch/build/src/libqpid-dispatch.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-core.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-core.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-proactor.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/libqpid-proton-proactor.so.11.0.0 changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libpthread-2.24.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libpthread-2.24.so 
changed: replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/librt-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/librt-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libdl-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of /usr/lib/x86_64-linux-gnu/libdl-2.24.so changed: 
replay divergence likely, but continuing anyway ...
[ERROR /build/rr-7gSJ0G/rr-4.5.0/src/TraceStream.cc:484:read_mapped_region() 
errno: SUCCESS] Metadata of 

[jira] [Updated] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-02 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-782:

Attachment: rr-4dd876.zip

[~ganeshmurthy] it should be possible to run this with {{rr replay [OPTION]... 
[]}}; If done it the container, then paths to binaries and so on 
would match. I don't know if the trace contains enough info not to need the 
original binary... I guess not.

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core, rr-4dd876.zip, rr.zip
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.641383 + AGENT (debug) Add entity: 
> LogEntity(identity=log/MESSAGE, module=MESSAGE, name=log/MESSAGE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.642008 + AGENT (debug) Add entity: 
> ContainerEntity(containerName=----, 
> identity=container/----, 
> name=container/----, 
> type=org.apache.qpid.dispatch.container, workerThreads=4)
> 9: 2017-05-30 13:23:52.642676 + AGENT (debug) Add entity: 
> RouterEntity(allowUnsettledMulticast=False, area=0, helloInterval=1, 
> helloMaxAge=3, id=QDR, mobileAddrMaxAge=60, mode=standalone, raInterval=30, 
> raIntervalFlux=4, 

[jira] [Comment Edited] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-02 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111070#comment-16111070
 ] 

Jiri Danek edited comment on DISPATCH-782 at 8/2/17 3:02 PM:
-

[~ganeshmurthy] Updated trace attached. it should be possible to run this with 
{{rr replay [OPTION]... []}}; If done it the container, then paths 
to binaries and so on would match. I don't know if the trace contains enough 
info not to need the original binary... I guess not.


was (Author: jdanek):
[~ganeshmurthy] it should be possible to run this with {{rr replay [OPTION]... 
[]}}; If done it the container, then paths to binaries and so on 
would match. I don't know if the trace contains enough info not to need the 
original binary... I guess not.

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core, rr-4dd876.zip, rr.zip
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.641383 + AGENT (debug) Add entity: 
> LogEntity(identity=log/MESSAGE, module=MESSAGE, name=log/MESSAGE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.642008 + AGENT (debug) Add entity: 
> ContainerEntity(containerName=----, 
> 

[jira] [Commented] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-08-02 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110483#comment-16110483
 ] 

Jiri Danek commented on PROTON-1484:


I cannot reproduce this on master anymore.

Tested version on Debian Testing in Docker:
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}

{noformat}
commit b79759d6dbd2f542086bb6bcb3c94806ed818b5a
Author: Cliff Jansen 
Date:   Fri Jul 28 16:44:18 2017 -0700

PROTON-1394: Python client resource cleanup, circular references and 
underlying C objects
{noformat}

> [c proactor] SIGSEGV in pconnection_cleanup
> ---
>
> Key: PROTON-1484
> URL: https://issues.apache.org/jira/browse/PROTON-1484
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: latest git tip for both qpid proton and qpid dispatch on 
> Debian
>Reporter: Jiri Danek
> Attachments: PROTON-1484_1.core.zip, PROTON-1484_2.core.zip
>
>
> I've noticed multiple qdrouterd test failures with seem to come from the same 
> place in proactor code.
> SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
> /main/qpid-proton/proton-c/src/proactor/epoll.c:645 
> stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);
> Reproducibility: the issue seems nondeterministic
> I am attaching logs and backtraces from two of them below.
> {noformat}
> test 14
>   Start 14: system_tests_autolinks
> 14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_autolinks"
> 14: Test timeout computed to be: 1500
> 14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
> 14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) 
> ... ok
> 14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ok
> 14: test_07_autolink_attach_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: FAIL
> 14: test_08_autolink_sender_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: 

[jira] [Closed] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-08-02 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek closed PROTON-1484.
--

> [c proactor] SIGSEGV in pconnection_cleanup
> ---
>
> Key: PROTON-1484
> URL: https://issues.apache.org/jira/browse/PROTON-1484
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: latest git tip for both qpid proton and qpid dispatch on 
> Debian
>Reporter: Jiri Danek
> Attachments: PROTON-1484_1.core.zip, PROTON-1484_2.core.zip
>
>
> I've noticed multiple qdrouterd test failures with seem to come from the same 
> place in proactor code.
> SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
> /main/qpid-proton/proton-c/src/proactor/epoll.c:645 
> stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);
> Reproducibility: the issue seems nondeterministic
> I am attaching logs and backtraces from two of them below.
> {noformat}
> test 14
>   Start 14: system_tests_autolinks
> 14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_autolinks"
> 14: Test timeout computed to be: 1500
> 14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
> 14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) 
> ... ok
> 14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ok
> 14: test_07_autolink_attach_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: FAIL
> 14: test_08_autolink_sender_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: 

[jira] [Resolved] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-08-02 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek resolved PROTON-1484.

Resolution: Cannot Reproduce

> [c proactor] SIGSEGV in pconnection_cleanup
> ---
>
> Key: PROTON-1484
> URL: https://issues.apache.org/jira/browse/PROTON-1484
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: latest git tip for both qpid proton and qpid dispatch on 
> Debian
>Reporter: Jiri Danek
> Attachments: PROTON-1484_1.core.zip, PROTON-1484_2.core.zip
>
>
> I've noticed multiple qdrouterd test failures with seem to come from the same 
> place in proactor code.
> SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
> /main/qpid-proton/proton-c/src/proactor/epoll.c:645 
> stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);
> Reproducibility: the issue seems nondeterministic
> I am attaching logs and backtraces from two of them below.
> {noformat}
> test 14
>   Start 14: system_tests_autolinks
> 14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_autolinks"
> 14: Test timeout computed to be: 1500
> 14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
> 14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) 
> ... ok
> 14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ok
> 14: test_07_autolink_attach_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: FAIL
> 14: test_08_autolink_sender_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: 

[jira] [Closed] (DISPATCH-778) [system_tests_two_routers] qd_hash_internal_remove_item: Assertion `(bucket->items).size > 0' failed.

2017-08-02 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek closed DISPATCH-778.
---

> [system_tests_two_routers] qd_hash_internal_remove_item: Assertion 
> `(bucket->items).size > 0' failed.
> -
>
> Key: DISPATCH-778
> URL: https://issues.apache.org/jira/browse/DISPATCH-778
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
> Environment: git tip of both proton and dispatch on debian testing
> {noformat}
> commit f7490003d3d88ee695cdbaaee887fb0c22a140a0
> Author: Andrew Stitcher 
> Date:   Fri May 19 09:54:00 2017 -0400
> NO-JIRA: Ensure _GNU_SOURCE & _POSIX_C_SOURCE are not redefined
> {noformat}
> {noformat}
> commit 8c9f4a581f7a62158d21bbe845edb3db60ae1d06
> Author: Ganesh Murthy 
> Date:   Tue May 16 11:25:39 2017 -0400
> NO-JIRA - Added extra documentation for the logMessage field. Thank you 
> Gordon Sim
> {noformat}
>Reporter: Jiri Danek
> Attachments: system_tests_two_routers.core.zip
>
>
> Reproducible essentially every time with the following command (although it 
> might take many iterations)
> {{ctest -VV -R system_tests_two_routers --repeat-until-fail 1000}}
> {noformat}
> test 27
>   Start 27: system_tests_two_routers
> 27: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_two_routers"
> 27: Test timeout computed to be: 1500
> 27: test_01_pre_settled (system_tests_two_routers.RouterTest) ... ok
> 27: test_02a_multicast_unsettled (system_tests_two_routers.RouterTest) ... ok
> 27: test_02c_sender_settles_first (system_tests_two_routers.RouterTest) ... ok
> 27: test_03_propagated_disposition (system_tests_two_routers.RouterTest) ... 
> ok
> 27: test_04_unsettled_undeliverable (system_tests_two_routers.RouterTest) ... 
> ok
> 27: test_05_three_ack (system_tests_two_routers.RouterTest) ... ok
> 27: test_08_message_annotations (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_strip_message_annotations_custom 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_both_add_ingress_trace 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_in 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_no 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_no_add_trace 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_out 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_out_custom 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_09_management (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_10_semantics_multicast (system_tests_two_routers.RouterTest) ... 
> recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_11a_semantics_closest_is_local (system_tests_two_routers.RouterTest) 
> ... recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_11b_semantics_closest_is_remote 
> (system_tests_two_routers.RouterTest) ... recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_12_semantics_spread (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_13_to_override (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_14_excess_deliveries_released (system_tests_two_routers.RouterTest) 
> ... ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: 

[jira] [Resolved] (DISPATCH-778) [system_tests_two_routers] qd_hash_internal_remove_item: Assertion `(bucket->items).size > 0' failed.

2017-08-02 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek resolved DISPATCH-778.
-
Resolution: Cannot Reproduce

I cannot reproduce this on master anymore.

Tested version on Debian Testing in Docker:
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}

{noformat}
commit b79759d6dbd2f542086bb6bcb3c94806ed818b5a
Author: Cliff Jansen 
Date:   Fri Jul 28 16:44:18 2017 -0700

PROTON-1394: Python client resource cleanup, circular references and 
underlying C objects
{noformat}

> [system_tests_two_routers] qd_hash_internal_remove_item: Assertion 
> `(bucket->items).size > 0' failed.
> -
>
> Key: DISPATCH-778
> URL: https://issues.apache.org/jira/browse/DISPATCH-778
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
> Environment: git tip of both proton and dispatch on debian testing
> {noformat}
> commit f7490003d3d88ee695cdbaaee887fb0c22a140a0
> Author: Andrew Stitcher 
> Date:   Fri May 19 09:54:00 2017 -0400
> NO-JIRA: Ensure _GNU_SOURCE & _POSIX_C_SOURCE are not redefined
> {noformat}
> {noformat}
> commit 8c9f4a581f7a62158d21bbe845edb3db60ae1d06
> Author: Ganesh Murthy 
> Date:   Tue May 16 11:25:39 2017 -0400
> NO-JIRA - Added extra documentation for the logMessage field. Thank you 
> Gordon Sim
> {noformat}
>Reporter: Jiri Danek
> Attachments: system_tests_two_routers.core.zip
>
>
> Reproducible essentially every time with the following command (although it 
> might take many iterations)
> {{ctest -VV -R system_tests_two_routers --repeat-until-fail 1000}}
> {noformat}
> test 27
>   Start 27: system_tests_two_routers
> 27: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_two_routers"
> 27: Test timeout computed to be: 1500
> 27: test_01_pre_settled (system_tests_two_routers.RouterTest) ... ok
> 27: test_02a_multicast_unsettled (system_tests_two_routers.RouterTest) ... ok
> 27: test_02c_sender_settles_first (system_tests_two_routers.RouterTest) ... ok
> 27: test_03_propagated_disposition (system_tests_two_routers.RouterTest) ... 
> ok
> 27: test_04_unsettled_undeliverable (system_tests_two_routers.RouterTest) ... 
> ok
> 27: test_05_three_ack (system_tests_two_routers.RouterTest) ... ok
> 27: test_08_message_annotations (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_strip_message_annotations_custom 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_both_add_ingress_trace 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_in 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_no 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_no_add_trace 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_out 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_out_custom 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_09_management (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_10_semantics_multicast (system_tests_two_routers.RouterTest) ... 
> recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_11a_semantics_closest_is_local (system_tests_two_routers.RouterTest) 
> ... recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_11b_semantics_closest_is_remote 
> (system_tests_two_routers.RouterTest) ... recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_12_semantics_spread (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_13_to_override (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_14_excess_deliveries_released (system_tests_two_routers.RouterTest) 
> ... ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 

[jira] [Commented] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

2017-08-02 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110400#comment-16110400
 ] 

Jiri Danek commented on DISPATCH-782:
-

[~ganeshmurthy] The bug is still present in current master. The test output and 
stack trace look the same. I could rerecord the rr trace if you use that tool 
(and consider it useful, and if traces are portable between machines; I never 
tried that)

Tested version on Debian Testing in Docker
{noformat}
commit 4dd8764b341cdf9e1d5c06c99697f454d4eaa468
Author: Ganesh Murthy 
Date:   Mon Jul 31 17:09:30 2017 -0400

DISPATCH-799 - Fixed CMakeLists.txt to set the TEST_RUNNER variable 
correctly
{noformat}

{noformat}
commit b79759d6dbd2f542086bb6bcb3c94806ed818b5a
Author: Cliff Jansen 
Date:   Fri Jul 28 16:44:18 2017 -0700

PROTON-1394: Python client resource cleanup, circular references and 
underlying C objects
{noformat}

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core, rr.zip
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.641383 + AGENT (debug) Add entity: 
> LogEntity(identity=log/MESSAGE, module=MESSAGE, name=log/MESSAGE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 

[jira] [Created] (QPIDJMS-298) Use online service to manage and display coverage reports

2017-07-11 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-298:
--

 Summary: Use online service to manage and display coverage reports
 Key: QPIDJMS-298
 URL: https://issues.apache.org/jira/browse/QPIDJMS-298
 Project: Qpid JMS
  Issue Type: Wish
  Components: qpid-jms-client, qpid-jms-discovery
Affects Versions: 0.24.0
Reporter: Jiri Danek
Priority: Minor


There are multiple coverage monitoring online services that integrate with 
popular CI services, like TravisCI.

I propose uploading coverage report from run in TravisCI to some coverage 
monitoring service. This way, test coverage will become more visible.



--
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] (DISPATCH-753) Neither version of console is usable on Internet Explorer 10 or 11

2017-06-20 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055791#comment-16055791
 ] 

Jiri Danek edited comment on DISPATCH-753 at 6/20/17 2:11 PM:
--

works for me now; there is still one minor issue I noticed, reported as 
DISPATCH-793


was (Author: jdanek):
works for me now

> Neither version of console is usable on Internet Explorer 10 or 11
> --
>
> Key: DISPATCH-753
> URL: https://issues.apache.org/jira/browse/DISPATCH-753
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.8.0
> Environment: Windows 7, Internet Explorer 10 and 11 (running in a 
> virtual machine provided at 
> https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
>Reporter: Jiri Danek
>Assignee: Ernest Allen
> Fix For: 1.0.0
>
>
> This is a complete console output from Hawtio version on WIndows 7 and 
> Internet Explorer 10
> {noformat}
> SCRIPT1002: Syntax error 
> hawtio, line 955 character 19
> [Window] Syntax error (:955:19) 
> [PluginLoader] Failed loading script: "Could not complete the operation due 
> to error 80020101." ( href="/dispatch-hawtio-console/plugin/js/qdrOverview.js:undefined">/dispatch-hawtio-console/plugin/js/qdrOverview.js:undefined)
>  
> SCRIPT1006: Expected ')' 
> hawtio, line 492 character 45
> [Window] Expected ')' (:492:45) 
> [PluginLoader] Failed loading script: "Could not complete the operation due 
> to error 80020101." ( href="/dispatch-hawtio-console/plugin/js/qdrTopology.js:undefined">/dispatch-hawtio-console/plugin/js/qdrTopology.js:undefined)
>  
> [Themes] unknown theme name, using default theme 
> [QDR] *creating Dispatch Console 
> [QDR] curPath is / 
> [Core] hawtio started 
> [RBAC] Using mbean 
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity for 
> client-side role based access control 
> XML5632: Only one root element is allowed. 
> , line 3 character 2
> [QDR] okay to start 
> [QDR] [
>   "amqp:/_topo/0/Router.A/$management"
> ] 
> [QDR] {
>   "amqp:/_topo/0/Router.A/$management": {}
> } 
> [QDR] saving page changed to /dispatch_hawtio_console/overview 
> Error: Error: Argument 'QDR.OverviewController' is not a function, got 
> undefined 
> Stack trace: 
> Error: Argument 'QDR.OverviewController' is not a function, got 
> undefined
>at _ 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:8946)
>at aa 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:9037)
>at Anonymous function 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:28890)
>at Anonymous function 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:24327)
>at f 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:3544)
>at n 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:24131)
>at f 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:22086)
>at Anonymous function 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:21616)
>at k 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:15:22785)
>at $broadcast 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:14:17750)
> 
> {noformat}
> This is complete output from stand-alone version on the same system Windows 7 
> and Internet Explorer 10
> {noformat}
> SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 200,  
> [connection-1] error: [object Event] 
> [connection-1] disconnected  
> [connection-1] disconnected  
> QDR: routeChangeSuccess: path is now / 
> Error: [$controller:ctrlreg] The controller with the name 
> 'QDR.OverviewController' is not registered.
> http://errors.angularjs.org/1.6.2/$controller/ctrlreg?p0=QDR.OverviewController
>at $controller 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10690:11)
>at setupControllers 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9779:9)
>at nodeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9549:11)
>at compositeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8903:13)
>at publicLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8768:30)
>at link 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular-route.min.js:7:490)
>at Anonymous function 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:1290:11)
>at invokeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10274:9)
>at nodeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9663:11)
>at compositeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8903:13)  

[jira] [Updated] (DISPATCH-793) Edge between nodes in Topology diagram missing on IE11

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-793:

Attachment: no_edge_between_nodes.png

> Edge between nodes in Topology diagram missing on IE11
> --
>
> Key: DISPATCH-793
> URL: https://issues.apache.org/jira/browse/DISPATCH-793
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Dispatch and Dispatch plugin at commit e22091b3
>Reporter: Jiri Danek
>Priority: Minor
> Attachments: no_edge_between_nodes.png
>
>
> !no_edge_between_nodes.png!



--
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] (DISPATCH-793) Edge between nodes in Topology diagram missing on IE11

2017-06-20 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-793:
---

 Summary: Edge between nodes in Topology diagram missing on IE11
 Key: DISPATCH-793
 URL: https://issues.apache.org/jira/browse/DISPATCH-793
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Dispatch and Dispatch plugin at commit e22091b3
Reporter: Jiri Danek
Priority: Minor


!no_edge_between_nodes.png!



--
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] (DISPATCH-753) Neither version of console is usable on Internet Explorer 10 or 11

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek closed DISPATCH-753.
---

works for me now

> Neither version of console is usable on Internet Explorer 10 or 11
> --
>
> Key: DISPATCH-753
> URL: https://issues.apache.org/jira/browse/DISPATCH-753
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.8.0
> Environment: Windows 7, Internet Explorer 10 and 11 (running in a 
> virtual machine provided at 
> https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
>Reporter: Jiri Danek
>Assignee: Ernest Allen
> Fix For: 1.0.0
>
>
> This is a complete console output from Hawtio version on WIndows 7 and 
> Internet Explorer 10
> {noformat}
> SCRIPT1002: Syntax error 
> hawtio, line 955 character 19
> [Window] Syntax error (:955:19) 
> [PluginLoader] Failed loading script: "Could not complete the operation due 
> to error 80020101." ( href="/dispatch-hawtio-console/plugin/js/qdrOverview.js:undefined">/dispatch-hawtio-console/plugin/js/qdrOverview.js:undefined)
>  
> SCRIPT1006: Expected ')' 
> hawtio, line 492 character 45
> [Window] Expected ')' (:492:45) 
> [PluginLoader] Failed loading script: "Could not complete the operation due 
> to error 80020101." ( href="/dispatch-hawtio-console/plugin/js/qdrTopology.js:undefined">/dispatch-hawtio-console/plugin/js/qdrTopology.js:undefined)
>  
> [Themes] unknown theme name, using default theme 
> [QDR] *creating Dispatch Console 
> [QDR] curPath is / 
> [Core] hawtio started 
> [RBAC] Using mbean 
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity for 
> client-side role based access control 
> XML5632: Only one root element is allowed. 
> , line 3 character 2
> [QDR] okay to start 
> [QDR] [
>   "amqp:/_topo/0/Router.A/$management"
> ] 
> [QDR] {
>   "amqp:/_topo/0/Router.A/$management": {}
> } 
> [QDR] saving page changed to /dispatch_hawtio_console/overview 
> Error: Error: Argument 'QDR.OverviewController' is not a function, got 
> undefined 
> Stack trace: 
> Error: Argument 'QDR.OverviewController' is not a function, got 
> undefined
>at _ 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:8946)
>at aa 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:9037)
>at Anonymous function 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:28890)
>at Anonymous function 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:24327)
>at f 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:3544)
>at n 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:24131)
>at f 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:22086)
>at Anonymous function 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:13:21616)
>at k 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:15:22785)
>at $broadcast 
> (http://10.0.2.2:8080/hawtio/app/app.js?c8641b2e13788127:14:17750)
> 
> {noformat}
> This is complete output from stand-alone version on the same system Windows 7 
> and Internet Explorer 10
> {noformat}
> SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 200,  
> [connection-1] error: [object Event] 
> [connection-1] disconnected  
> [connection-1] disconnected  
> QDR: routeChangeSuccess: path is now / 
> Error: [$controller:ctrlreg] The controller with the name 
> 'QDR.OverviewController' is not registered.
> http://errors.angularjs.org/1.6.2/$controller/ctrlreg?p0=QDR.OverviewController
>at $controller 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10690:11)
>at setupControllers 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9779:9)
>at nodeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9549:11)
>at compositeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8903:13)
>at publicLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8768:30)
>at link 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular-route.min.js:7:490)
>at Anonymous function 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:1290:11)
>at invokeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:10274:9)
>at nodeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:9663:11)
>at compositeLinkFn 
> (https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:8903:13)  class="ng-scope" ng-view=""> 
>  QDR: failed to auto-connect to 10.0.2.2:8080 
> QDR: routeChangeSuccess: path is now /connect 
> $tooltip is now deprecated. Use $uibTooltip instead. 
>  QDR: ** 

[jira] [Closed] (DISPATCH-762) Hawtio console does not show details about a connection whereas stand-alone console does

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek closed DISPATCH-762.
---

Works for me in build from master, commit e22091b3

> Hawtio console does not show details about a connection whereas stand-alone 
> console does
> 
>
> Key: DISPATCH-762
> URL: https://issues.apache.org/jira/browse/DISPATCH-762
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: vlcsnap-2017-05-04-14h05m40s322.png
>
>
> 1) Open hawtio console and go to Overview tab.
> 2) Expand the Connections node in the tree on the left
> 3) Click one of the individual connections.
> 4) Note that connection details in the right pane are empty!
> If you find the same connection on the Entities tab of the console, the 
> details will be displayed there.
> See the screenshot below, or a screen recording at 
> https://www.youtube.com/watch?v=9Hv7iNuDZQs
> !vlcsnap-2017-05-04-14h05m40s322.png!



--
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] (DISPATCH-772) Buttons to Create and Delete entity disappear after navigation in either version of console

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek closed DISPATCH-772.
---

Fixed in current master, commit e22091b3

> Buttons to Create and Delete entity disappear after navigation in either 
> version of console
> ---
>
> Key: DISPATCH-772
> URL: https://issues.apache.org/jira/browse/DISPATCH-772
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 0.8.1, 1.0.0
>
>
> 1) Navigate to the Entities tab in the Console.
> 2) Have the address node open; the Create and Delete buttons are visible
> 3) Navigate to the Topology tab in the Console and then back to the Entities 
> tab
> 4) The page looks the same way as before, except the Create and Delete 
> buttons are now missing.
> https://www.youtube.com/watch?v=8jLH5MPHx4c



--
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] (DISPATCH-792) Freezing and moving nodes is somewhat broken (in either version of console)

2017-06-20 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-792:
---

 Summary: Freezing and moving nodes is somewhat broken (in either 
version of console)
 Key: DISPATCH-792
 URL: https://issues.apache.org/jira/browse/DISPATCH-792
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Dispatch and Dispatch plugin at commit e22091b3
Built without libwebsocket, used the old websockify way to connect console
Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
Reporter: Jiri Danek
Priority: Minor


If I freeze a node using the right-click menu, then

1) The label in the popup menu randomly switches Freeze/Unfreeze and it is 
tricky to click the Unfreeze option: https://youtu.be/DwczdnMnnkc

if I am dragging a frozen router node on top of console node, then

2) The legend switches to the other node. I would expect it not to change. 
https://www.youtube.com/watch?v=HSCxFvFnfTs

3) If I put the nodes exactly on top of each other, I get the following 
exception in browser log.

{noformat}
Error:  attribute d: Expected number, "MNaN,NaNLNaN,NaN".
a   @   d3.min.js?_=1497955959439:1
(anonymous) @   d3.min.js?_=1497955959439:3
Y   @   d3.min.js?_=1497955959439:1
Aa.each @   d3.min.js?_=1497955959439:3
Aa.attr @   d3.min.js?_=1497955959439:3
tick@   VM79:1125
t   @   d3.min.js?_=1497955959439:1
l.tick  @   d3.min.js?_=1497955959439:4
Rn  @   d3.min.js?_=1497955959439:1
Tn  @   d3.min.js?_=1497955959439:1
{noformat}

Issue 3 is very hard to reproduce, I was able to trigger it two times in hawtio 
version of console, and then never. Unless it can be figured out from code what 
could went wrong, it is probably not worth the time to investigate further.



--
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] (DISPATCH-789) Console breaks when quickly moving between tabs (both hawtio and stand-alone)

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-789:

Description: 
If I open Dispatch plugin, log in, and quickly switch between tabs in Dispatch 
plugin, the plugin stops working eventually.

See https://www.youtube.com/watch?v=sDLLXAWEVdg

h3. Logs for hawtio version of console

{noformat}
Error: TypeError: tree.getNodeByKey is not a function
at updateLeaves (eval at  (app.js?c8641b2e13788127:1), 
:1402:29)
at eval (eval at  (app.js?c8641b2e13788127:1), 
:1452:29)
at app.js?c8641b2e13788127:14
at g (app.js?c8641b2e13788127:13)
at app.js?c8641b2e13788127:13
consoleLogger @ app.js?c8641b2e13788127:16
c @ app.js?c8641b2e13788127:16
(anonymous) @ app.js?c8641b2e13788127:16
invoke @ app.js?c8641b2e13788127:4
error @ app.js?c8641b2e13788127:4
(anonymous) @ app.js?c8641b2e13788127:4
(anonymous) @ app.js?c8641b2e13788127:14
(anonymous) @ app.js?c8641b2e13788127:13
(anonymous) @ app.js?c8641b2e13788127:14
g @ app.js?c8641b2e13788127:13
(anonymous) @ app.js?c8641b2e13788127:13
{noformat}

{noformat}
app.js?c8641b2e13788127:16 Stack trace:  
TypeError: tree.getNodeByKey is not a function
at updateLeaves (eval at  
(http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:1:26916), 
:1402:29)
at eval (eval at  
(http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:1:26916), 
:1452:29)
at http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:14:24956
at g 
(http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:13:17652)
at http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:13:19298

{noformat}

Or sometimes (same as in DISPATCH-791)

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

Or sometimes

{noformat}
app.js?c8641b2e13788127:16 [Window] Script error.  (:0)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

At some point, the JavaScript in the dispatch plugin completely breaks and 
almost nothing no longer works.

h3. The stand-alone console

It shows some errors in browser log too, before it breaks

{noformat}
TypeError: Cannot read property 'find' of null
at l.setDraggables (ng-grid.min.js:1)
at angular.js:19964
at completeOutstandingRequest (angular.js:6131)
at angular.js:6411
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
(anonymous) @ angular.js:19967
completeOutstandingRequest @ angular.js:6131
(anonymous) @ angular.js:6411

angular.js:14362 TypeError: Cannot read property 'find' of null
at l.setDraggables 
(https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.js:1:17852)
at https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:19964:31
at completeOutstandingRequest 
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:6131:10)
at https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:6411:7 
Possibly unhandled rejection: {}
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
processChecks @ angular.js:16715
$eval @ angular.js:18017
$digest @ angular.js:17827
$apply @ angular.js:18125
(anonymous) @ angular.js:19972
completeOutstandingRequest @ angular.js:6131
(anonymous) @ angular.js:6411

angular.js:14362 TypeError: Cannot read property 'find' of null
at l.setDraggables (ng-grid.min.js:1)
at angular.js:19964
at completeOutstandingRequest (angular.js:6131)
at angular.js:6411
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
(anonymous) @ angular.js:19967
completeOutstandingRequest @ angular.js:6131
(anonymous) @ angular.js:6411

angular.js:14362 TypeError: Cannot read property 'find' of null
at l.setDraggables 
(https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.js:1:17852)
at https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:19964:31
at completeOutstandingRequest 
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:6131:10)
at https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:6411:7 
Possibly unhandled rejection: {}
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
processChecks @ angular.js:16715
$eval @ angular.js:18017
$digest @ angular.js:17827
$apply @ 

[jira] [Updated] (DISPATCH-790) The right-mouse-click menu on Topology tab appears off-center in the stand-alone console

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-790:

Description: 
The hawtio version of console is not affected.

See https://www.youtube.com/watch?v=77ksxAiMxv0 for a demonstration. (The 
hawtio part at 0:00, stand-alone part at 0:17. The hawtio part is manifesting 
what I reported in DISPATCH-791, which is likely unrelated to this problem.)

  was:
The hawtio version of console is not affected.

See https://www.youtube.com/watch?v=77ksxAiMxv0 for a demonstration. (The 
hawtio part at 0:00, stand-alone part at 0:17. The hawtio part is manifesting 
what I reported in ?jira to come?, which is likely unrelated to this problem.)


> The right-mouse-click menu on Topology tab appears off-center in the 
> stand-alone console
> 
>
> Key: DISPATCH-790
> URL: https://issues.apache.org/jira/browse/DISPATCH-790
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Dispatch and Dispatch plugin at commit e22091b3
> Built without libwebsocket, used the old websockify way to connect console
> Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
>Reporter: Jiri Danek
>
> The hawtio version of console is not affected.
> See https://www.youtube.com/watch?v=77ksxAiMxv0 for a demonstration. (The 
> hawtio part at 0:00, stand-alone part at 0:17. The hawtio part is manifesting 
> what I reported in DISPATCH-791, which is likely unrelated to this problem.)



--
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] (DISPATCH-791) The node representing Console in Topology tab is not displayed

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-791:

Description: 
Both hawtio and stand-alone versions are affected. Issue was observed in Chrome 
and Firefox. In Firefox, if I move to another panel and back, the console node 
sometimes appears. In Chrome, it usually appears the first time and then 
disappears.

Video: https://youtu.be/q3_8HT4iVzc

The following exception is displayed in browser console (from hawtio version)

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

in stand-alone version, it is

{noformat}
Uncaught TypeError: Cannot read property 'results' of undefined
at initializeLinks (qdrTopology.js:723)
at qdrTopology.js:1009
at qdrService.js:440
at i._call (d3-queue.min.js:2)
at s (d3-queue.min.js:2)
at d3-queue.min.js:2
at qdrService.js:668
at Object.resolver (qdrService.js:813)
at Object.resolve (qdrService.js:172)
at Receiver. (qdrService.js:1073)
angular.js:14362 QDR: GET-MGMT-NODES returned an empty list. Using [...]
{noformat}

  was:
Both hawtio and stand-alone versions are affected. Issue was observed in Chrome 
and Firefox. In Firefox, if I move to another panel and back, the console node 
sometimes appears. In Chrome, it usually appears the first time and then 
disappears.

The following exception is displayed in browser console (from hawtio version)

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

in stand-alone version, it is

{noformat}
Uncaught TypeError: Cannot read property 'results' of undefined
at initializeLinks (qdrTopology.js:723)
at qdrTopology.js:1009
at qdrService.js:440
at i._call (d3-queue.min.js:2)
at s (d3-queue.min.js:2)
at d3-queue.min.js:2
at qdrService.js:668
at Object.resolver (qdrService.js:813)
at Object.resolve (qdrService.js:172)
at Receiver. (qdrService.js:1073)
angular.js:14362 QDR: GET-MGMT-NODES returned an empty list. Using [...]
{noformat}


> The node representing Console in Topology tab is not displayed
> --
>
> Key: DISPATCH-791
> URL: https://issues.apache.org/jira/browse/DISPATCH-791
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Dispatch and Dispatch plugin at commit e22091b3
> Built without libwebsocket, used the old websockify way to connect console
> Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
>Reporter: Jiri Danek
>
> Both hawtio and stand-alone versions are affected. Issue was observed in 
> Chrome and Firefox. In Firefox, if I move to another panel and back, the 
> console node sometimes appears. In Chrome, it usually appears the first time 
> and then disappears.
> Video: https://youtu.be/q3_8HT4iVzc
> The following exception is displayed in browser console (from hawtio version)
> {noformat}
> app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
> 'results' of undefined  ( href="http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
> consoleLogger @   app.js?c8641b2e13788127:16
> c @   app.js?c8641b2e13788127:16
> (anonymous)   @   app.js?c8641b2e13788127:16
> invoke@   app.js?c8641b2e13788127:4
> error @   app.js?c8641b2e13788127:4
> window.onerror@   app.js?c8641b2e13788127:16
> {noformat}
> in stand-alone version, it is
> {noformat}
> Uncaught TypeError: Cannot read property 'results' of undefined
> at initializeLinks (qdrTopology.js:723)
> at qdrTopology.js:1009
> at qdrService.js:440
> at i._call (d3-queue.min.js:2)
> at s (d3-queue.min.js:2)
> at d3-queue.min.js:2
> at qdrService.js:668
> at Object.resolver (qdrService.js:813)
> at Object.resolve 

[jira] [Updated] (DISPATCH-791) The node representing Console in Topology tab is not displayed

2017-06-20 Thread Jiri Danek (JIRA)

 [ 
https://issues.apache.org/jira/browse/DISPATCH-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-791:

Description: 
Both hawtio and stand-alone versions are affected. Issue was observed in Chrome 
and Firefox. In Firefox, if I move to another panel and back, the console node 
sometimes appears. In Chrome, it usually appears the first time and then 
disappears.

The following exception is displayed in browser console (from hawtio version)

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

in stand-alone version, it is

{noformat}
Uncaught TypeError: Cannot read property 'results' of undefined
at initializeLinks (qdrTopology.js:723)
at qdrTopology.js:1009
at qdrService.js:440
at i._call (d3-queue.min.js:2)
at s (d3-queue.min.js:2)
at d3-queue.min.js:2
at qdrService.js:668
at Object.resolver (qdrService.js:813)
at Object.resolve (qdrService.js:172)
at Receiver. (qdrService.js:1073)
angular.js:14362 QDR: GET-MGMT-NODES returned an empty list. Using [...]
{noformat}

  was:
Both hawtio and stand-alone versions are affected. Issue was observed in Chrome 
and Firefox. If I move to another panel and back, the console node sometimes 
appears.

The following exception is displayed in browser console (from hawtio version)

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

in stand-alone version, it is

{noformat}
Uncaught TypeError: Cannot read property 'results' of undefined
at initializeLinks (qdrTopology.js:723)
at qdrTopology.js:1009
at qdrService.js:440
at i._call (d3-queue.min.js:2)
at s (d3-queue.min.js:2)
at d3-queue.min.js:2
at qdrService.js:668
at Object.resolver (qdrService.js:813)
at Object.resolve (qdrService.js:172)
at Receiver. (qdrService.js:1073)
angular.js:14362 QDR: GET-MGMT-NODES returned an empty list. Using [...]
{noformat}


> The node representing Console in Topology tab is not displayed
> --
>
> Key: DISPATCH-791
> URL: https://issues.apache.org/jira/browse/DISPATCH-791
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.0.0
> Environment: Dispatch and Dispatch plugin at commit e22091b3
> Built without libwebsocket, used the old websockify way to connect console
> Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
>Reporter: Jiri Danek
>
> Both hawtio and stand-alone versions are affected. Issue was observed in 
> Chrome and Firefox. In Firefox, if I move to another panel and back, the 
> console node sometimes appears. In Chrome, it usually appears the first time 
> and then disappears.
> The following exception is displayed in browser console (from hawtio version)
> {noformat}
> app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
> 'results' of undefined  ( href="http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
> consoleLogger @   app.js?c8641b2e13788127:16
> c @   app.js?c8641b2e13788127:16
> (anonymous)   @   app.js?c8641b2e13788127:16
> invoke@   app.js?c8641b2e13788127:4
> error @   app.js?c8641b2e13788127:4
> window.onerror@   app.js?c8641b2e13788127:16
> {noformat}
> in stand-alone version, it is
> {noformat}
> Uncaught TypeError: Cannot read property 'results' of undefined
> at initializeLinks (qdrTopology.js:723)
> at qdrTopology.js:1009
> at qdrService.js:440
> at i._call (d3-queue.min.js:2)
> at s (d3-queue.min.js:2)
> at d3-queue.min.js:2
> at qdrService.js:668
> at Object.resolver (qdrService.js:813)
> at Object.resolve (qdrService.js:172)
> at Receiver. (qdrService.js:1073)
> angular.js:14362 QDR: GET-MGMT-NODES returned an empty list. Using [...]
> {noformat}



--

[jira] [Created] (DISPATCH-791) The node representing Console in Topology tab is not displayed

2017-06-20 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-791:
---

 Summary: The node representing Console in Topology tab is not 
displayed
 Key: DISPATCH-791
 URL: https://issues.apache.org/jira/browse/DISPATCH-791
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Dispatch and Dispatch plugin at commit e22091b3
Built without libwebsocket, used the old websockify way to connect console
Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
Reporter: Jiri Danek


Both hawtio and stand-alone versions are affected. Issue was observed in Chrome 
and Firefox. If I move to another panel and back, the console node sometimes 
appears.

The following exception is displayed in browser console (from hawtio version)

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

in stand-alone version, it is

{noformat}
Uncaught TypeError: Cannot read property 'results' of undefined
at initializeLinks (qdrTopology.js:723)
at qdrTopology.js:1009
at qdrService.js:440
at i._call (d3-queue.min.js:2)
at s (d3-queue.min.js:2)
at d3-queue.min.js:2
at qdrService.js:668
at Object.resolver (qdrService.js:813)
at Object.resolve (qdrService.js:172)
at Receiver. (qdrService.js:1073)
angular.js:14362 QDR: GET-MGMT-NODES returned an empty list. Using [...]
{noformat}



--
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] (DISPATCH-790) The right-mouse-click menu on Topology tab appears off-center in the stand-alone console

2017-06-20 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-790:
---

 Summary: The right-mouse-click menu on Topology tab appears 
off-center in the stand-alone console
 Key: DISPATCH-790
 URL: https://issues.apache.org/jira/browse/DISPATCH-790
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Dispatch and Dispatch plugin at commit e22091b3
Built without libwebsocket, used the old websockify way to connect console
Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
Reporter: Jiri Danek


The hawtio version of console is not affected.

See https://www.youtube.com/watch?v=77ksxAiMxv0 for a demonstration. (The 
hawtio part at 0:00, stand-alone part at 0:17. The hawtio part is manifesting 
what I reported in ?jira to come?, which is likely unrelated to this problem.)



--
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] (DISPATCH-789) Console breaks when quickly moving between tabs (both hawtio and stand-alone)

2017-06-20 Thread Jiri Danek (JIRA)
Jiri Danek created DISPATCH-789:
---

 Summary: Console breaks when quickly moving between tabs (both 
hawtio and stand-alone)
 Key: DISPATCH-789
 URL: https://issues.apache.org/jira/browse/DISPATCH-789
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.0
 Environment: Dispatch and Dispatch plugin at commit e22091b3
Built without libwebsocket, used the old websockify way to connect console
Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
Reporter: Jiri Danek


If I open Dispatch plugin, log in, and quickly switch between tabs in Dispatch 
plugin, the plugin stops working eventually.

See https://www.youtube.com/watch?v=sDLLXAWEVdg

h3. Logs for hawtio version of console

{noformat}
Error: TypeError: tree.getNodeByKey is not a function
at updateLeaves (eval at  (app.js?c8641b2e13788127:1), 
:1402:29)
at eval (eval at  (app.js?c8641b2e13788127:1), 
:1452:29)
at app.js?c8641b2e13788127:14
at g (app.js?c8641b2e13788127:13)
at app.js?c8641b2e13788127:13
consoleLogger @ app.js?c8641b2e13788127:16
c @ app.js?c8641b2e13788127:16
(anonymous) @ app.js?c8641b2e13788127:16
invoke @ app.js?c8641b2e13788127:4
error @ app.js?c8641b2e13788127:4
(anonymous) @ app.js?c8641b2e13788127:4
(anonymous) @ app.js?c8641b2e13788127:14
(anonymous) @ app.js?c8641b2e13788127:13
(anonymous) @ app.js?c8641b2e13788127:14
g @ app.js?c8641b2e13788127:13
(anonymous) @ app.js?c8641b2e13788127:13
{noformat}

{noformat}
app.js?c8641b2e13788127:16 Stack trace:  
TypeError: tree.getNodeByKey is not a function
at updateLeaves (eval at  
(http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:1:26916), 
:1402:29)
at eval (eval at  
(http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:1:26916), 
:1452:29)
at http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:14:24956
at g 
(http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:13:17652)
at http://127.0.0.1:8080/hawtio/app/app.js?c8641b2e13788127:13:19298

{noformat}

Or sometimes (same as in )

{noformat}
app.js?c8641b2e13788127:16 [Window] Uncaught TypeError: Cannot read property 
'results' of undefined  (http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5;>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/topology:5:8603)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

Or sometimes

{noformat}
app.js?c8641b2e13788127:16 [Window] Script error.  (:0)
consoleLogger   @   app.js?c8641b2e13788127:16
c   @   app.js?c8641b2e13788127:16
(anonymous) @   app.js?c8641b2e13788127:16
invoke  @   app.js?c8641b2e13788127:4
error   @   app.js?c8641b2e13788127:4
window.onerror  @   app.js?c8641b2e13788127:16
{noformat}

At some point, the JavaScript in the dispatch plugin completely breaks and 
almost nothing no longer works.

h3. The stand-alone console

It shows some errors in browser log too, before it breaks

{noformat}
TypeError: Cannot read property 'find' of null
at l.setDraggables (ng-grid.min.js:1)
at angular.js:19964
at completeOutstandingRequest (angular.js:6131)
at angular.js:6411
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
(anonymous) @ angular.js:19967
completeOutstandingRequest @ angular.js:6131
(anonymous) @ angular.js:6411

angular.js:14362 TypeError: Cannot read property 'find' of null
at l.setDraggables 
(https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.js:1:17852)
at https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:19964:31
at completeOutstandingRequest 
(https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:6131:10)
at https://ajax.googleapis.com/ajax/libs/angularjs/1.6.2/angular.js:6411:7 
Possibly unhandled rejection: {}
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
processChecks @ angular.js:16715
$eval @ angular.js:18017
$digest @ angular.js:17827
$apply @ angular.js:18125
(anonymous) @ angular.js:19972
completeOutstandingRequest @ angular.js:6131
(anonymous) @ angular.js:6411

angular.js:14362 TypeError: Cannot read property 'find' of null
at l.setDraggables (ng-grid.min.js:1)
at angular.js:19964
at completeOutstandingRequest (angular.js:6131)
at angular.js:6411
(anonymous) @ angular.js:14362
(anonymous) @ angular.js:10859
(anonymous) @ angular.js:19967
completeOutstandingRequest @ angular.js:6131
(anonymous) @ angular.js:6411

angular.js:14362 TypeError: Cannot read property 'find' of null
at l.setDraggables 
(https://cdnjs.cloudflare.com/ajax/libs/ng-grid/2.0.11/ng-grid.min.js:1:17852)
at 

[jira] [Comment Edited] (PROTON-1497) python program crash on send msg to queue

2017-06-19 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054040#comment-16054040
 ] 

Jiri Danek edited comment on PROTON-1497 at 6/19/17 1:59 PM:
-

Probably use the heartbeat parameter on 
https://qpid.apache.org/releases/qpid-proton-master/proton/python/api/proton.reactor.Container-class.html#connect.
 That is the way to configure the idle timeout.


was (Author: jdanek):
Probably use the heartbeat parameter on 
https://qpid.apache.org/releases/qpid-proton-master/proton/python/api/proton.reactor.Container-class.html#connect.

> python program crash on send msg to queue
> -
>
> Key: PROTON-1497
> URL: https://issues.apache.org/jira/browse/PROTON-1497
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.17.0
> Environment: redhat 7.2 - activemq-5.14.3 - Python 3.6.0
>Reporter: Pier Paolo Panto
> Attachments: md5.py
>
>
> In the attached file there is an on_message method that performs a lenghty 
> calculation whenever a message is receivede on the input queue. In this case, 
> the branch that gets executed is the one starting at line 123. 
> A the end of the branch a new message is created and sent so an out queue.
> The problem is that if the calculation takes a long time (>1min) to finish, 
> randomly the program crashes when trying to execute the send instruction 
>  (line 157). I also tryed to encapsulate the send into a try/except clause, 
> but the code inside the except never gets executed. 
> Moreover, the exit code (echo $?) when the program crashes is 0
> When this happens, I get this message in the log file:
> handlers.py:234 in print_error(): local-idle-timeout expired
> but setting the timeout parameters for the connection has no effect.
> What could be causing this behaviour?
> Best Regard,
> PPP



--
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] (PROTON-1497) python program crash on send msg to queue

2017-06-19 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054040#comment-16054040
 ] 

Jiri Danek commented on PROTON-1497:


Probably use the heartbeat parameter on 
https://qpid.apache.org/releases/qpid-proton-master/proton/python/api/proton.reactor.Container-class.html#connect.

> python program crash on send msg to queue
> -
>
> Key: PROTON-1497
> URL: https://issues.apache.org/jira/browse/PROTON-1497
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.17.0
> Environment: redhat 7.2 - activemq-5.14.3 - Python 3.6.0
>Reporter: Pier Paolo Panto
> Attachments: md5.py
>
>
> In the attached file there is an on_message method that performs a lenghty 
> calculation whenever a message is receivede on the input queue. In this case, 
> the branch that gets executed is the one starting at line 123. 
> A the end of the branch a new message is created and sent so an out queue.
> The problem is that if the calculation takes a long time (>1min) to finish, 
> randomly the program crashes when trying to execute the send instruction 
>  (line 157). I also tryed to encapsulate the send into a try/except clause, 
> but the code inside the except never gets executed. 
> Moreover, the exit code (echo $?) when the program crashes is 0
> When this happens, I get this message in the log file:
> handlers.py:234 in print_error(): local-idle-timeout expired
> but setting the timeout parameters for the connection has no effect.
> What could be causing this behaviour?
> Best Regard,
> PPP



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



  1   2   3   4   5   >