[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
[ https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7958: - Attachment: release_system_sources_messages.diff > [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties > node retained by store > > > Key: QPID-7958 > URL: https://issues.apache.org/jira/browse/QPID-7958 > Project: Qpid > Issue Type: Bug >Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3 >Reporter: Keith Wall >Priority: Critical > Attachments: release_system_sources_messages.diff > > > On the 0-10 path, I notice that references to messages created by the > {{${virtualhostProperties\}}} node are being retained internally within the > store. This is leaking approximately ~1024 bytes per connection. Restarting > the Broker or recycling the virtualhost frees the memory. > The reference are being retained by the {{AbstractXXXMessageStore#_messages}} > set. > From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer > taking/releasing of the message reference that causes the store to forget the > message. It looks like > org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else > path) should have something equivalent. > QPID-7783 added the _messages data structure. It was back ported to 6.0 and > 6.1, so the leak might be present there too. I have not verify 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] [Resolved] (PROTON-1604) Windows C++ prefers std::endl to newlines
[ https://issues.apache.org/jira/browse/PROTON-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1604. -- Resolution: Fixed > Windows C++ prefers std::endl to newlines > - > > Key: PROTON-1604 > URL: https://issues.apache.org/jira/browse/PROTON-1604 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 > Environment: Visual Studio >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > Using C newline escaped char sequence can result in mysteriously missing > output. > Use std::endl instead of \\n. -- 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-1601) windows proactor fails ipv6 target ":::5672"
[ https://issues.apache.org/jira/browse/PROTON-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1601. -- Resolution: Fixed > windows proactor fails ipv6 target ":::5672" > > > Key: PROTON-1601 > URL: https://issues.apache.org/jira/browse/PROTON-1601 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > fails with "The format of the specified network name is invalid". > Other ipv6 specific tests are OK. -- 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-1601) windows proactor fails ipv6 target ":::5672"
[ https://issues.apache.org/jira/browse/PROTON-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193867#comment-16193867 ] ASF subversion and git services commented on PROTON-1601: - Commit 446ade386dab7e0cf163f435beee467e0e294c93 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=446ade3 ] PROTON-1601: make Windows more like Posix in handling the unpecified address for outbound connections > windows proactor fails ipv6 target ":::5672" > > > Key: PROTON-1601 > URL: https://issues.apache.org/jira/browse/PROTON-1601 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > fails with "The format of the specified network name is invalid". > Other ipv6 specific tests are OK. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193484#comment-16193484 ] ASF subversion and git services commented on QPID-7531: --- Commit 634eb6a90f221eced9e3ff971846a574de8f87ad in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=634eb6a ] QPID-7531: [Java Broker] Add more transaction tests to AMQP 1.0 protocol tests > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193481#comment-16193481 ] ASF subversion and git services commented on QPID-7531: --- Commit 876ddd6dd04246a0a2605ef709081f44d42661d1 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=876ddd6 ] QPID-7531: [Java Broker, AMQP 1.0] Improve error handling when receiving unknown a transaction-id. > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193485#comment-16193485 ] ASF subversion and git services commented on QPID-7531: --- Commit 6a7633d0ba1361a69f8249fffb72a23d8ceb7fc0 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6a7633d ] QPID-7531: [Java Broker, AMQP 1.0] Allow receiving of Transfers on semi-detached links but end the session if link is errored > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193483#comment-16193483 ] ASF subversion and git services commented on QPID-7531: --- Commit a963d54d1df8e0a8de0b0b6e7189e56ebe5fd32a in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a963d54 ] QPID-7531: [Java Broker] add JIRA references to TODOs > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193488#comment-16193488 ] ASF subversion and git services commented on QPID-7531: --- Commit 016279faac0cd0feb2a1208b3ae2bf6d5edadcfb in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=016279f ] QPID-7531: [Java Broker, AMQP 1.0] Improve links recovering > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7957) [Java Broker, AMQP 1.0] Add support for max-message-size on Attach
[ https://issues.apache.org/jira/browse/QPID-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193487#comment-16193487 ] ASF subversion and git services commented on QPID-7957: --- Commit 103251579d14b82559386f45437e9ea65beca636 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=1032515 ] QPID-7957: [Java Broker, AMQP 1.0] Add support for max-message-size on Attach > [Java Broker, AMQP 1.0] Add support for max-message-size on Attach > -- > > Key: QPID-7957 > URL: https://issues.apache.org/jira/browse/QPID-7957 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > Currently the max-message-size on Attach is never set by the broker. > We should set it to the limit configured on the Connection/VirtualHost and > enforce it upon receiving Transfers. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193486#comment-16193486 ] ASF subversion and git services commented on QPID-7531: --- Commit c1dabe6810300e57824148a5a28e4eca1702907c in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c1dabe6 ] QPID-7531: [Java Broker, AMQP 1.0] Improve reported error conditions > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193489#comment-16193489 ] ASF subversion and git services commented on QPID-7531: --- Commit 2736b3b7d5faed6ea51b8e08e650ca40162e3072 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2736b3b ] QPID-7531: [Java Broker, AMQP 1.0] Ensure consumer target is closed on detaching of sending link endpoint > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7950) [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach does not apply the correct outcomes
[ https://issues.apache.org/jira/browse/QPID-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193482#comment-16193482 ] ASF subversion and git services commented on QPID-7950: --- Commit 6b44f4129f61818a4a095fdc515508fea47450b2 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6b44f41 ] QPID-7950: [Java Broker, AMQP 1.0] Allow (semi-)detached Link endpoints to communicate indirectly via session. > [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach > does not apply the correct outcomes > -- > > Key: QPID-7950 > URL: https://issues.apache.org/jira/browse/QPID-7950 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack >Priority: Blocker > Fix For: qpid-java-broker-7.0.0 > > > Consider the following scenario: > * declare transaction > * receive a delivery > * detach the consumer > * send disposition with txn-state and Accepted outcome > * discharge the transaction > After this message should be deleted from the broker. It currently is not. > Currently, detaching the link applies the Modified outcome to all unsettled > messages therefore the disposition and discharge have no effect on them. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193490#comment-16193490 ] ASF subversion and git services commented on QPID-7531: --- Commit fb93bae6368dffce01b6e0261617c9b3ce6c48fe in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=fb93bae ] QPID-7531: [Java Broker, AMQP 1.0] Improve reporting of error condition on link attachments > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code. This must > include improvements to the performative constructors that currently swallow > incorrectly composed performative (i.e. they swallow ClassCastExceptions). -- 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-852) Add dispatch router installation procedure to main book
Ben Hardesty created DISPATCH-852: - Summary: Add dispatch router installation procedure to main book Key: DISPATCH-852 URL: https://issues.apache.org/jira/browse/DISPATCH-852 Project: Qpid Dispatch Issue Type: Sub-task Components: Documentation Reporter: Ben Hardesty Assignee: Ben Hardesty The QDR installation procedure [1] should be included in the main Dispatch Router book. It should include both installing from source and installing from a package on Linux [2]. [1] - https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb=0.8.0 [2] - https://qpid.apache.org/packages.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-851) Update CMakeLists.txt to build new Dispatch Router Book
[ https://issues.apache.org/jira/browse/DISPATCH-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193434#comment-16193434 ] Ben Hardesty commented on DISPATCH-851: --- [~jr...@redhat.com], as I thought about this, I think what will work best for now is to just have one "book" with all of the content in it and then have links to the relevant chapters from the Qpid Dispatch Router site. Since there will only be one book, the directory can remain "book". If we ever have need for additional books in the future, we could always change it to "books" with separate dirs for each book. > Update CMakeLists.txt to build new Dispatch Router Book > --- > > Key: DISPATCH-851 > URL: https://issues.apache.org/jira/browse/DISPATCH-851 > Project: Qpid Dispatch > Issue Type: Sub-task > Components: Documentation >Reporter: Ben Hardesty >Assignee: Justin Ross > > CMakeLists.txt should build the new Dispatch Router book, currently located > in /doc/new-book/. > * The new book should be built using AsciiDoctor instead of AsciiDoc Python > (additional info here: > http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python). > * For copying the book dir images, note that the images are now located in > /doc/new-book/images/. Before, they were located in /doc/book/. -- 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-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[ https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193414#comment-16193414 ] ASF GitHub Bot commented on PROTON-1606: GitHub user timtay-microsoft opened a pull request: https://github.com/apache/qpid-proton-j/pull/11 PROTON-1606: Added ability to make SASL communication optional Previously, the IOhandler created to be the global handler automatically created the SASL layer whether a user of the library wanted it or not. This commit exposes an option when creating the reactor to disable creating the SASL layer at all. https://issues.apache.org/jira/browse/PROTON-1606 You can merge this pull request into a Git repository by running: $ git pull https://github.com/timtay-microsoft/qpid-proton-j clientSaslOptionality Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton-j/pull/11.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #11 commit 965bc73893f887a15b1558891039d0a5cb7556eb Author: timtay-microsoft Date: 2017-10-05T18:40:28Z PROTON-1606: Added ability to make SASL communication optional for CLIENT role Previously, the IOhandler created to be the global handler automatically created the SASL layer whether a user of the library wanted it or not. This commit exposes an option when creating the reactor to disable creating the SASL layer at all. https://issues.apache.org/jira/browse/PROTON-1606 > (Proton-J) Using Sasl needs to be optional for Client Role > -- > > Key: PROTON-1606 > URL: https://issues.apache.org/jira/browse/PROTON-1606 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.22.0 > Environment: N/A >Reporter: Tim Taylor > Original Estimate: 8h > Remaining Estimate: 8h > > In order for my application to use Proton-j for amqps messaging, the Sasl > layer cannot be created by the global handler (IOHandler) at > CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j > for amqps messaging as a CLIENT against our service. > ... > sasl = transport.sasl(); > sasl.client(); > sasl.setMechanisms("ANONYMOUS"); > ... > I need these three lines of code to be optional in the global handler, or for > a new API that allows a transport implementation to undo creating the Sasl > layer. > Something like: > > Transport transport = event.getConnection().getTransport(); > transport.disableSasl(); > > The service I am hitting against is not using Proton-j as the SERVER role. -- 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
[GitHub] qpid-proton-j pull request #11: PROTON-1606: Added ability to make SASL comm...
GitHub user timtay-microsoft opened a pull request: https://github.com/apache/qpid-proton-j/pull/11 PROTON-1606: Added ability to make SASL communication optional Previously, the IOhandler created to be the global handler automatically created the SASL layer whether a user of the library wanted it or not. This commit exposes an option when creating the reactor to disable creating the SASL layer at all. https://issues.apache.org/jira/browse/PROTON-1606 You can merge this pull request into a Git repository by running: $ git pull https://github.com/timtay-microsoft/qpid-proton-j clientSaslOptionality Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton-j/pull/11.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #11 commit 965bc73893f887a15b1558891039d0a5cb7556eb Author: timtay-microsoft Date: 2017-10-05T18:40:28Z PROTON-1606: Added ability to make SASL communication optional for CLIENT role Previously, the IOhandler created to be the global handler automatically created the SASL layer whether a user of the library wanted it or not. This commit exposes an option when creating the reactor to disable creating the SASL layer at all. https://issues.apache.org/jira/browse/PROTON-1606 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #206: Dispatch 829 3
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/206 Dispatch 829 3 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-829-3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/206.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #206 commit 4ea149a5ff0a854daa15a7ade16c29ca0636b0e2 Author: Chuck Rolke Date: 2017-09-28T14:35:45Z DISPATCH-829: Sense messages received with abort status. commit 87bef2ccf183ed8525c7f155b49af199dc8e1c3e Author: Chuck Rolke Date: 2017-10-02T20:06:57Z DISPATCH-829: handle aborted messages --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-851) Update CMakeLists.txt to build new Dispatch Router Book
[ https://issues.apache.org/jira/browse/DISPATCH-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193173#comment-16193173 ] Justin Ross commented on DISPATCH-851: -- [~bhardest], I thought the plan was to go to something like doc/books/? In either case, no problem. We can track that in another issue. > Update CMakeLists.txt to build new Dispatch Router Book > --- > > Key: DISPATCH-851 > URL: https://issues.apache.org/jira/browse/DISPATCH-851 > Project: Qpid Dispatch > Issue Type: Sub-task > Components: Documentation >Reporter: Ben Hardesty >Assignee: Justin Ross > > CMakeLists.txt should build the new Dispatch Router book, currently located > in /doc/new-book/. > * The new book should be built using AsciiDoctor instead of AsciiDoc Python > (additional info here: > http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python). > * For copying the book dir images, note that the images are now located in > /doc/new-book/images/. Before, they were located in /doc/book/. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
[ https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7958: - Priority: Critical (was: Major) > [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties > node retained by store > > > Key: QPID-7958 > URL: https://issues.apache.org/jira/browse/QPID-7958 > Project: Qpid > Issue Type: Bug >Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3 >Reporter: Keith Wall >Priority: Critical > > On the 0-10 path, I notice that references to messages created by the > {{${virtualhostProperties\}}} node are being retained internally within the > store. This is leaking approximately ~1024 bytes per connection. Restarting > the Broker or recycling the virtualhost frees the memory. > The reference are being retained by the {{AbstractXXXMessageStore#_messages}} > set. > From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer > taking/releasing of the message reference that causes the store to forget the > message. It looks like > org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else > path) should have something equivalent. > QPID-7783 added the _messages data structure. It was back ported to 6.0 and > 6.1, so the leak might be present there too. I have not verify 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] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
[ https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7958: - Affects Version/s: qpid-java-6.0.7 qpid-java-6.1.3 > [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties > node retained by store > > > Key: QPID-7958 > URL: https://issues.apache.org/jira/browse/QPID-7958 > Project: Qpid > Issue Type: Bug >Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3 >Reporter: Keith Wall > > On the 0-10 path, I notice that references to messages created by the > {{${virtualhostProperties\}}} node are being retained internally within the > store. This is leaking approximately ~1024 bytes per connection. Restarting > the Broker or recycling the virtualhost frees the memory. > The reference are being retained by the {{AbstractXXXMessageStore#_messages}} > set. > From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer > taking/releasing of the message reference that causes the store to forget the > message. It looks like > org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else > path) should have something equivalent. > QPID-7783 added the _messages data structure. It was back ported to 6.0 and > 6.1, so the leak might be present there too. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
[ https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7958: - Affects Version/s: qpid-java-broker-7.0.0 > [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties > node retained by store > > > Key: QPID-7958 > URL: https://issues.apache.org/jira/browse/QPID-7958 > Project: Qpid > Issue Type: Bug >Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3 >Reporter: Keith Wall > > On the 0-10 path, I notice that references to messages created by the > {{${virtualhostProperties\}}} node are being retained internally within the > store. This is leaking approximately ~1024 bytes per connection. Restarting > the Broker or recycling the virtualhost frees the memory. > The reference are being retained by the {{AbstractXXXMessageStore#_messages}} > set. > From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer > taking/releasing of the message reference that causes the store to forget the > message. It looks like > org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else > path) should have something equivalent. > QPID-7783 added the _messages data structure. It was back ported to 6.0 and > 6.1, so the leak might be present there too. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
[ https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7958: - Description: On the 0-10 path, I notice that references to messages created by the {{${virtualhostProperties\}}} node are being retained internally within the store. This is leaking approximately ~1024 bytes per connection. Restarting the Broker or recycling the virtualhost frees the memory. The reference are being retained by the {{AbstractXXXMessageStore#_messages}} set. >From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer >taking/releasing of the message reference that causes the store to forget the >message. It looks like >org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else >path) should have something equivalent. QPID-7783 added the _messages data structure. It was back ported to 6.0 and 6.1, so the leak might be present there too. I have not verify this. was: On the 0-10 path, I notice that references to messages created by the {{${virtualhostProperties\}}} node are being retained internally within the store. This is leaking approximately ~1024 bytes per connection. Restarting the Broker or recycling the virtualhost frees the memory. The reference are being retained by the {{AbstractXXXMessageStore#_messages}} set. >From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer >taking/releasing of the message reference that causes the store to forget the >message. It looks like >org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else >path) should have something equivalent. QPID-7783 added the _messages data structure. It was back ported to 6.0 and 6.1, so the leak might be present there too. > [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties > node retained by store > > > Key: QPID-7958 > URL: https://issues.apache.org/jira/browse/QPID-7958 > Project: Qpid > Issue Type: Bug >Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3 >Reporter: Keith Wall > > On the 0-10 path, I notice that references to messages created by the > {{${virtualhostProperties\}}} node are being retained internally within the > store. This is leaking approximately ~1024 bytes per connection. Restarting > the Broker or recycling the virtualhost frees the memory. > The reference are being retained by the {{AbstractXXXMessageStore#_messages}} > set. > From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer > taking/releasing of the message reference that causes the store to forget the > message. It looks like > org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else > path) should have something equivalent. > QPID-7783 added the _messages data structure. It was back ported to 6.0 and > 6.1, so the leak might be present there too. I have not verify 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] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
[ https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7958: - Description: On the 0-10 path, I notice that references to messages created by the {{${virtualhostProperties\}}} node are being retained internally within the store. This is leaking approximately ~1024 bytes per connection. Restarting the Broker or recycling the virtualhost frees the memory. The reference are being retained by the {{AbstractXXXMessageStore#_messages}} set. >From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer >taking/releasing of the message reference that causes the store to forget the >message. It looks like >org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else >path) should have something equivalent. QPID-7783 added the _messages data structure. It was back ported to 6.0 and 6.1, so the leak might be present there too. was: On the 0-10 path, I notice that references to messages created by the ${virtualhostProperties} node are being retained internally within the store. This is leaking approximately ~1024 bytes per connection. Restarting the Broker or recycling the virtualhost frees the memory. The reference are being retained by the {{AbstractXXXMessageStore#_messages}} set. >From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer >taking/releasing of the message reference that causes the store to forget the >message. It looks like >org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else >path) should have something equivalent. QPID-7783 added the _messages data structure. It was back ported to 6.0 and 6.1, so the leak might be present there too. > [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties > node retained by store > > > Key: QPID-7958 > URL: https://issues.apache.org/jira/browse/QPID-7958 > Project: Qpid > Issue Type: Bug >Reporter: Keith Wall > > On the 0-10 path, I notice that references to messages created by the > {{${virtualhostProperties\}}} node are being retained internally within the > store. This is leaking approximately ~1024 bytes per connection. Restarting > the Broker or recycling the virtualhost frees the memory. > The reference are being retained by the {{AbstractXXXMessageStore#_messages}} > set. > From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer > taking/releasing of the message reference that causes the store to forget the > message. It looks like > org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else > path) should have something equivalent. > QPID-7783 added the _messages data structure. It was back ported to 6.0 and > 6.1, so the leak might be present there too. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store
Keith Wall created QPID-7958: Summary: [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store Key: QPID-7958 URL: https://issues.apache.org/jira/browse/QPID-7958 Project: Qpid Issue Type: Bug Reporter: Keith Wall On the 0-10 path, I notice that references to messages created by the ${virtualhostProperties} node are being retained internally within the store. This is leaking approximately ~1024 bytes per connection. Restarting the Broker or recycling the virtualhost frees the memory. The reference are being retained by the {{AbstractXXXMessageStore#_messages}} set. >From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer >taking/releasing of the message reference that causes the store to forget the >message. It looks like >org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else >path) should have something equivalent. QPID-7783 added the _messages data structure. It was back ported to 6.0 and 6.1, so the leak might be present there too. -- 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] (PROTON-344) Need Ruby version of msgr-send/msgr-recv tools
[ https://issues.apache.org/jira/browse/PROTON-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed PROTON-344. - Resolution: Won't Fix lack of support for messenger > Need Ruby version of msgr-send/msgr-recv tools > -- > > Key: PROTON-344 > URL: https://issues.apache.org/jira/browse/PROTON-344 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: message, messenger > > A ruby variant of msgr-send/recv traffic generators should be added to the > soak tests. -- 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-851) Update CMakeLists.txt to build new Dispatch Router Book
[ https://issues.apache.org/jira/browse/DISPATCH-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192973#comment-16192973 ] Ben Hardesty commented on DISPATCH-851: --- [~jr...@redhat.com] - Eventually, the /doc/new-book/ dir should be changed to /doc/book/, and the contents of the current /doc/book/ dir should be retired/archived. However, I didn't specify any of that yet in case you'd rather build both the current Dispatch Router book and the new one. > Update CMakeLists.txt to build new Dispatch Router Book > --- > > Key: DISPATCH-851 > URL: https://issues.apache.org/jira/browse/DISPATCH-851 > Project: Qpid Dispatch > Issue Type: Sub-task > Components: Documentation >Reporter: Ben Hardesty >Assignee: Justin Ross > > CMakeLists.txt should build the new Dispatch Router book, currently located > in /doc/new-book/. > * The new book should be built using AsciiDoctor instead of AsciiDoc Python > (additional info here: > http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python). > * For copying the book dir images, note that the images are now located in > /doc/new-book/images/. Before, they were located in /doc/book/. -- 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-851) Update CMakeLists.txt to build new Dispatch Router Book
Ben Hardesty created DISPATCH-851: - Summary: Update CMakeLists.txt to build new Dispatch Router Book Key: DISPATCH-851 URL: https://issues.apache.org/jira/browse/DISPATCH-851 Project: Qpid Dispatch Issue Type: Sub-task Components: Documentation Reporter: Ben Hardesty Assignee: Justin Ross CMakeLists.txt should build the new Dispatch Router book, currently located in /doc/new-book/. * The new book should be built using AsciiDoctor instead of AsciiDoc Python (additional info here: http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python). * For copying the book dir images, note that the images are now located in /doc/new-book/images/. Before, they were located in /doc/book/. -- 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-1573) Undefined behavior in some calls to memmove in Proton
[ https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1573. - Resolution: Fixed > 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 Daněk >Assignee: Alan Conway >Priority: Trivial > Fix For: proton-c-0.18.0 > > > 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(&bytes[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] [Commented] (PROTON-1573) Undefined behavior in some calls to memmove in Proton
[ https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192912#comment-16192912 ] Justin Ross commented on PROTON-1573: - Thanks, [~jdanek]. > 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 Daněk >Assignee: Alan Conway >Priority: Trivial > Fix For: proton-c-0.18.0 > > > 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(&bytes[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-1613) Default value for Messenger::recv is -1, not 2048
[ https://issues.apache.org/jira/browse/PROTON-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1613: Labels: messenger (was: ) > Default value for Messenger::recv is -1, not 2048 > - > > Key: PROTON-1613 > URL: https://issues.apache.org/jira/browse/PROTON-1613 > Project: Qpid Proton > Issue Type: Bug > Components: examples >Affects Versions: 0.17.0 >Reporter: Jiri Daněk >Priority: Trivial > Labels: messenger > > {code} > diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js > index 24bdcae7..f1353685 100755 > --- a/tests/javascript/msgr-recv.js > +++ b/tests/javascript/msgr-recv.js > @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === > 'function') { > 'Usage: msgr-recv [OPTIONS]\n' + > ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' + > ' -c # \tNumber of messages to receive before exiting [0=forever]\n' + > -' -b # \tArgument to Messenger::recv(n) [2048]\n' + > +' -b # \tArgument to Messenger::recv(n) [-1]\n' + > ' -w # \tSize for incoming window [0]\n' + > ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' + > ' -R \tSend reply if \'reply-to\' present\n' + > diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c > index eff5820c..b87f29a8 100644 > --- a/tests/tools/apps/c/msgr-recv.c > +++ b/tests/tools/apps/c/msgr-recv.c > @@ -52,7 +52,7 @@ static void usage(int rc) > printf("Usage: msgr-recv [OPTIONS] \n" > " -a [,]* \tAddresses to listen on > [amqp://~0.0.0.0]\n" > " -c # \tNumber of messages to receive before exiting > [0=forever]\n" > - " -b # \tArgument to Messenger::recv(n) [2048]\n" > + " -b # \tArgument to Messenger::recv(n) [-1]\n" > " -w # \tSize for incoming window [0]\n" > " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n" > " -e # \t# seconds to report statistics, 0 = end of test [0] > *TBD*\n" > diff --git a/tests/tools/apps/python/msgr-recv.py > b/tests/tools/apps/python/msgr-recv.py > index 757b19c2..52fe69c3 100755 > --- a/tests/tools/apps/python/msgr-recv.py > +++ b/tests/tools/apps/python/msgr-recv.py > @@ -34,7 +34,7 @@ usage = """ > Usage: msgr-recv [OPTIONS] > -a [,]* \tAddresses to listen on [amqp://~0.0.0.0] > -c # \tNumber of messages to receive before exiting [0=forever] > - -b # \tArgument to Messenger::recv(n) [2048] > + -b # \tArgument to Messenger::recv(n) [-1] > -w # \tSize for incoming window [0] > -t # \tInactivity timeout in seconds, -1 = no timeout [-1] > -e # \t# seconds to report statistics, 0 = end of test [0] *TBD* > {code} > There may possibly be more discrepancies, I spotted and then was able to find > only this single one. The function in various bindings is usually not called > Messenger::recv... -- 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-850) Implement new Dispatch Router Book
Ben Hardesty created DISPATCH-850: - Summary: Implement new Dispatch Router Book Key: DISPATCH-850 URL: https://issues.apache.org/jira/browse/DISPATCH-850 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Reporter: Ben Hardesty Assignee: Ben Hardesty A new Dispatch Router user guide is available in /doc/new-book/. This new doc needs to be made available on the Qpid Dispatch website, and integrated into the Dispatch Router build tooling. -- 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-1613) Default value for Messenger::recv is -1, not 2048
[ https://issues.apache.org/jira/browse/PROTON-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk updated PROTON-1613: --- Description: {code} diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js index 24bdcae7..f1353685 100755 --- a/tests/javascript/msgr-recv.js +++ b/tests/javascript/msgr-recv.js @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 'function') { 'Usage: msgr-recv [OPTIONS]\n' + ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' + ' -c # \tNumber of messages to receive before exiting [0=forever]\n' + -' -b # \tArgument to Messenger::recv(n) [2048]\n' + +' -b # \tArgument to Messenger::recv(n) [-1]\n' + ' -w # \tSize for incoming window [0]\n' + ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' + ' -R \tSend reply if \'reply-to\' present\n' + diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c index eff5820c..b87f29a8 100644 --- a/tests/tools/apps/c/msgr-recv.c +++ b/tests/tools/apps/c/msgr-recv.c @@ -52,7 +52,7 @@ static void usage(int rc) printf("Usage: msgr-recv [OPTIONS] \n" " -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n" " -c # \tNumber of messages to receive before exiting [0=forever]\n" - " -b # \tArgument to Messenger::recv(n) [2048]\n" + " -b # \tArgument to Messenger::recv(n) [-1]\n" " -w # \tSize for incoming window [0]\n" " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n" " -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n" diff --git a/tests/tools/apps/python/msgr-recv.py b/tests/tools/apps/python/msgr-recv.py index 757b19c2..52fe69c3 100755 --- a/tests/tools/apps/python/msgr-recv.py +++ b/tests/tools/apps/python/msgr-recv.py @@ -34,7 +34,7 @@ usage = """ Usage: msgr-recv [OPTIONS] -a [,]* \tAddresses to listen on [amqp://~0.0.0.0] -c # \tNumber of messages to receive before exiting [0=forever] - -b # \tArgument to Messenger::recv(n) [2048] + -b # \tArgument to Messenger::recv(n) [-1] -w # \tSize for incoming window [0] -t # \tInactivity timeout in seconds, -1 = no timeout [-1] -e # \t# seconds to report statistics, 0 = end of test [0] *TBD* {code} There may possibly be more discrepancies, I spotted and then was able to find only this single one. The function in various bindings is usually not called Messenger::recv... was: {code} diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js index 24bdcae7..f1353685 100755 --- a/tests/javascript/msgr-recv.js +++ b/tests/javascript/msgr-recv.js @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 'function') { 'Usage: msgr-recv [OPTIONS]\n' + ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' + ' -c # \tNumber of messages to receive before exiting [0=forever]\n' + -' -b # \tArgument to Messenger::recv(n) [2048]\n' + +' -b # \tArgument to Messenger::recv(n) [-1]\n' + ' -w # \tSize for incoming window [0]\n' + ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' + ' -R \tSend reply if \'reply-to\' present\n' + diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c index eff5820c..b87f29a8 100644 --- a/tests/tools/apps/c/msgr-recv.c +++ b/tests/tools/apps/c/msgr-recv.c @@ -52,7 +52,7 @@ static void usage(int rc) printf("Usage: msgr-recv [OPTIONS] \n" " -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n" " -c # \tNumber of messages to receive before exiting [0=forever]\n" - " -b # \tArgument to Messenger::recv(n) [2048]\n" + " -b # \tArgument to Messenger::recv(n) [-1]\n" " -w # \tSize for incoming window [0]\n" " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n" " -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n" diff --git a/tests/tools/apps/python/msgr-recv.py b/tests/tools/apps/python/msgr-recv.py index 757b19c2..52fe69c3 100755 --- a/tests/tools/apps/python/msgr-recv.py +++ b/tests/tools/apps/python/msgr-recv.py @@ -34,7 +34,7 @@ usage = """ Usage: msgr-recv [OPTIONS] -a [,]* \tAddresses to listen on [amqp://~0.0.0.0] -c # \tNumber of messages to receive before exiting [0=forever] - -b # \tArgument to Messenger::recv(n) [2048] + -b # \tArgument to Messenger::recv(n) [-1] -w # \tSize for incoming window [0] -t # \tInactivity timeout in seconds, -1 = no timeout [-1] -e # \t# seconds to report statistics, 0 = end of test [0] *TBD* {code} There may possibly be more discrepancies, I spotted and then was able to find only this single one. > Default value for Messenger::recv is -1, not 2048 > - > > Key: PROTON-1613 > URL: https://issues.apache.org/jira/browse/PROTON-
[jira] [Updated] (PROTON-1613) Default value for Messenger::recv is -1, not 2048
[ https://issues.apache.org/jira/browse/PROTON-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk updated PROTON-1613: --- Summary: Default value for Messenger::recv is -1, not 2048 (was: Default value for is -1, not 2048) > Default value for Messenger::recv is -1, not 2048 > - > > Key: PROTON-1613 > URL: https://issues.apache.org/jira/browse/PROTON-1613 > Project: Qpid Proton > Issue Type: Bug > Components: examples >Affects Versions: 0.17.0 >Reporter: Jiri Daněk >Priority: Trivial > > {code} > diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js > index 24bdcae7..f1353685 100755 > --- a/tests/javascript/msgr-recv.js > +++ b/tests/javascript/msgr-recv.js > @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === > 'function') { > 'Usage: msgr-recv [OPTIONS]\n' + > ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' + > ' -c # \tNumber of messages to receive before exiting [0=forever]\n' + > -' -b # \tArgument to Messenger::recv(n) [2048]\n' + > +' -b # \tArgument to Messenger::recv(n) [-1]\n' + > ' -w # \tSize for incoming window [0]\n' + > ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' + > ' -R \tSend reply if \'reply-to\' present\n' + > diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c > index eff5820c..b87f29a8 100644 > --- a/tests/tools/apps/c/msgr-recv.c > +++ b/tests/tools/apps/c/msgr-recv.c > @@ -52,7 +52,7 @@ static void usage(int rc) > printf("Usage: msgr-recv [OPTIONS] \n" > " -a [,]* \tAddresses to listen on > [amqp://~0.0.0.0]\n" > " -c # \tNumber of messages to receive before exiting > [0=forever]\n" > - " -b # \tArgument to Messenger::recv(n) [2048]\n" > + " -b # \tArgument to Messenger::recv(n) [-1]\n" > " -w # \tSize for incoming window [0]\n" > " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n" > " -e # \t# seconds to report statistics, 0 = end of test [0] > *TBD*\n" > diff --git a/tests/tools/apps/python/msgr-recv.py > b/tests/tools/apps/python/msgr-recv.py > index 757b19c2..52fe69c3 100755 > --- a/tests/tools/apps/python/msgr-recv.py > +++ b/tests/tools/apps/python/msgr-recv.py > @@ -34,7 +34,7 @@ usage = """ > Usage: msgr-recv [OPTIONS] > -a [,]* \tAddresses to listen on [amqp://~0.0.0.0] > -c # \tNumber of messages to receive before exiting [0=forever] > - -b # \tArgument to Messenger::recv(n) [2048] > + -b # \tArgument to Messenger::recv(n) [-1] > -w # \tSize for incoming window [0] > -t # \tInactivity timeout in seconds, -1 = no timeout [-1] > -e # \t# seconds to report statistics, 0 = end of test [0] *TBD* > {code} > There may possibly be more discrepancies, I spotted and then was able to find > only this single one. -- 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-1613) Default value for is -1, not 2048
Jiri Daněk created PROTON-1613: -- Summary: Default value for is -1, not 2048 Key: PROTON-1613 URL: https://issues.apache.org/jira/browse/PROTON-1613 Project: Qpid Proton Issue Type: Bug Components: examples Affects Versions: 0.17.0 Reporter: Jiri Daněk Priority: Trivial {code} diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js index 24bdcae7..f1353685 100755 --- a/tests/javascript/msgr-recv.js +++ b/tests/javascript/msgr-recv.js @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 'function') { 'Usage: msgr-recv [OPTIONS]\n' + ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' + ' -c # \tNumber of messages to receive before exiting [0=forever]\n' + -' -b # \tArgument to Messenger::recv(n) [2048]\n' + +' -b # \tArgument to Messenger::recv(n) [-1]\n' + ' -w # \tSize for incoming window [0]\n' + ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' + ' -R \tSend reply if \'reply-to\' present\n' + diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c index eff5820c..b87f29a8 100644 --- a/tests/tools/apps/c/msgr-recv.c +++ b/tests/tools/apps/c/msgr-recv.c @@ -52,7 +52,7 @@ static void usage(int rc) printf("Usage: msgr-recv [OPTIONS] \n" " -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n" " -c # \tNumber of messages to receive before exiting [0=forever]\n" - " -b # \tArgument to Messenger::recv(n) [2048]\n" + " -b # \tArgument to Messenger::recv(n) [-1]\n" " -w # \tSize for incoming window [0]\n" " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n" " -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n" diff --git a/tests/tools/apps/python/msgr-recv.py b/tests/tools/apps/python/msgr-recv.py index 757b19c2..52fe69c3 100755 --- a/tests/tools/apps/python/msgr-recv.py +++ b/tests/tools/apps/python/msgr-recv.py @@ -34,7 +34,7 @@ usage = """ Usage: msgr-recv [OPTIONS] -a [,]* \tAddresses to listen on [amqp://~0.0.0.0] -c # \tNumber of messages to receive before exiting [0=forever] - -b # \tArgument to Messenger::recv(n) [2048] + -b # \tArgument to Messenger::recv(n) [-1] -w # \tSize for incoming window [0] -t # \tInactivity timeout in seconds, -1 = no timeout [-1] -e # \t# seconds to report statistics, 0 = end of test [0] *TBD* {code} There may possibly be more discrepancies, I spotted and then was able to find only this single one. -- 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
[ https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192810#comment-16192810 ] Jiri Daněk commented on PROTON-1573: This one here https://github.com/apache/qpid-proton/commit/feafb6c80b121f0a7ce87ea09c9b2f0f2d0fadf5 > 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 Daněk >Assignee: Alan Conway >Priority: Trivial > Fix For: proton-c-0.18.0 > > > 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(&bytes[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-1574) WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) due to missing unlock in stop_polling()
[ https://issues.apache.org/jira/browse/PROTON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1574: Fix Version/s: proton-c-0.18.0 > 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 Daněk >Assignee: Alan Conway > Fix For: proton-c-0.18.0 > > > 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(&ee->mutex); > - if (ee->fd == -1 || !ee->polling || epollfd == -1) > + if (ee->fd == -1 || !ee->polling || epollfd == -1) { > +unlock(&ee->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(&t) > 21: TEST: test_interrupt_timeout(&t) > 21: TEST: test_errors(&t) > 21: TEST: test_client_server(&t) > 21: TEST: test_connection_wake(&t) > 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+0x0
[jira] [Assigned] (PROTON-1573) Undefined behavior in some calls to memmove in Proton
[ https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1573: --- Assignee: Alan Conway > 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 Daněk >Assignee: Alan Conway >Priority: Trivial > Fix For: proton-c-0.18.0 > > > 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(&bytes[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-1573) Undefined behavior in some calls to memmove in Proton
[ https://issues.apache.org/jira/browse/PROTON-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1573: Fix Version/s: proton-c-0.18.0 > 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 Daněk >Priority: Trivial > Fix For: proton-c-0.18.0 > > > 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(&bytes[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] [Assigned] (PROTON-1571) The ssl C++ example appears leaky, proton::listener does not have a destructor
[ https://issues.apache.org/jira/browse/PROTON-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1571: --- Assignee: Alan Conway (was: Cliff Jansen) > 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 Daněk >Assignee: Alan Conway > Fix For: proton-c-0.18.0 > > > 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:certificat
[jira] [Updated] (PROTON-1571) The ssl C++ example appears leaky, proton::listener does not have a destructor
[ https://issues.apache.org/jira/browse/PROTON-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1571: Fix Version/s: proton-c-0.18.0 > 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 Daněk >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > 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 >
[jira] [Updated] (PROTON-1612) python test fail if Cyrus SASL PLAIN and MD5 packages not installed
[ https://issues.apache.org/jira/browse/PROTON-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1612: Component/s: (was: proton-c) > python test fail if Cyrus SASL PLAIN and MD5 packages not installed > --- > > Key: PROTON-1612 > URL: https://issues.apache.org/jira/browse/PROTON-1612 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.18.0 > Environment: clean centos 7 docker container >Reporter: Ken Giusti >Assignee: Justin Ross > Fix For: proton-c-0.18.0 > > > After following the directions in INSTALL.md, and installing the Python build > tools (python-devel), the python-test unit test fails the SASL tests. > 1: proton_tests.sasl.SASLMechTest.testDIGESTMD5 > fail > 1: Error during test: Traceback (most recent call last): > 1: File "/root/qpid-proton-0.18.0-beta/tests/python/proton-test", line > 365, in run > 1: phase() > 1: File > "/root/qpid-proton-0.18.0-beta/tests/python/proton_tests/sasl.py", line 326, > in testDIGESTMD5 > 1: _testSaslMech(self, 'DIGEST-MD5') > 1: File > "/root/qpid-proton-0.18.0-beta/tests/python/proton_tests/sasl.py", line 53, > in _testSaslMech > 1: assert self.t2.authenticated == authenticated, authenticated > 1: AssertionError: True > proton_tests.reactor.ContainerTest.test_authentication_via_url .. fail > > 1: File > "/root/qpid-proton-0.18.0-beta/tests/python/proton_tests/reactor.py", line > 339, in on_connection_opening > 1: assert event.connection.transport.user == "user@proton" > 1: AssertionError > These tests require MD5 and PLAIN support. The following packages must be > installed for the tests to pass: > $ yum install cyrus-sasl-plain cyrus-sasl-md5 > Either these packages must be listed as required in the INSTALL.md file, or > the tests should skip if these mechanisms are not available. -- 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-314) AssertionError from Netty during cleanup of Epoll channel with SO_LINGER configured
[ https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk closed QPIDJMS-314. -- Works for me in the 0.26.0 first release candidate. > AssertionError from Netty during cleanup of Epoll channel with SO_LINGER > configured > --- > > 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, 0.25.0 >Reporter: Jiri Daněk >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.26.0 > > > 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
[jira] [Created] (QPID-7957) [Java Broker, AMQP 1.0] Add support for max-message-size on Attach
Lorenz Quack created QPID-7957: -- Summary: [Java Broker, AMQP 1.0] Add support for max-message-size on Attach Key: QPID-7957 URL: https://issues.apache.org/jira/browse/QPID-7957 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Lorenz Quack Fix For: qpid-java-broker-7.0.0 Currently the max-message-size on Attach is never set by the broker. We should set it to the limit configured on the Connection/VirtualHost and enforce it upon receiving Transfers. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7059) BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on Apache CI
[ https://issues.apache.org/jira/browse/QPID-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192663#comment-16192663 ] Keith Wall edited comment on QPID-7059 at 10/5/17 9:30 AM: --- Repeat of same issue - log attached. The new logging shows us that the DbPing is giving us a non-zero value. The problem will be a race in the test code. The thread updating the remote node's attributes will be racing with the Jetty thread reading the attributes. The unlucky case is where the lastTransactionId has been read by Jetty and then the node state mutates. This will give the failure. was (Author: k-wall): Repeat of same issue - log attached. The new logging shows us that the DbPing is giving us a non-zero value. The problem must be within the Qpid code, but I can't spot it. > BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on > Apache CI > -- > > Key: QPID-7059 > URL: https://issues.apache.org/jira/browse/QPID-7059 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Attachments: > TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt > > > The following test was seen to fail on Apache CI: > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-10/2122/testReport/junit/org.apache.qpid.server.store.berkeleydb.replication/BDBHAVirtualHostNodeRestTest/testDeleteMasterNode/ > The test verifies that the remote view of the other nodes in the group is > populated. In this case the test failed because the node's join time is > recorded as zero. > {noformat} > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode > Failing for the past 1 build (Since Failed#2122 ) > Took 10 sec. > add description > Error Message > Node node2 has unexpected joinTime 0 > Stacktrace > junit.framework.AssertionFailedError: Node node2 has unexpected joinTime 0 > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodeData(BDBHAVirtualHostNodeRestTest.java:412) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodes(BDBHAVirtualHostNodeRestTest.java:397) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode(BDBHAVirtualHostNodeRestTest.java:206) > {noformat} > There were no further errors in the logs. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7059) BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on Apache CI
[ https://issues.apache.org/jira/browse/QPID-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192663#comment-16192663 ] Keith Wall commented on QPID-7059: -- Repeat of same issue - log attached. The new logging shows us that the DbPing is giving us a non-zero value. The problem must be within the Qpid code, but I can't spot it. > BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on > Apache CI > -- > > Key: QPID-7059 > URL: https://issues.apache.org/jira/browse/QPID-7059 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Attachments: > TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt > > > The following test was seen to fail on Apache CI: > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-10/2122/testReport/junit/org.apache.qpid.server.store.berkeleydb.replication/BDBHAVirtualHostNodeRestTest/testDeleteMasterNode/ > The test verifies that the remote view of the other nodes in the group is > populated. In this case the test failed because the node's join time is > recorded as zero. > {noformat} > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode > Failing for the past 1 build (Since Failed#2122 ) > Took 10 sec. > add description > Error Message > Node node2 has unexpected joinTime 0 > Stacktrace > junit.framework.AssertionFailedError: Node node2 has unexpected joinTime 0 > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodeData(BDBHAVirtualHostNodeRestTest.java:412) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodes(BDBHAVirtualHostNodeRestTest.java:397) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode(BDBHAVirtualHostNodeRestTest.java:206) > {noformat} > There were no further errors in the logs. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7059) BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on Apache CI
[ https://issues.apache.org/jira/browse/QPID-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7059: - Attachment: TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt > BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on > Apache CI > -- > > Key: QPID-7059 > URL: https://issues.apache.org/jira/browse/QPID-7059 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Attachments: > TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt > > > The following test was seen to fail on Apache CI: > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-10/2122/testReport/junit/org.apache.qpid.server.store.berkeleydb.replication/BDBHAVirtualHostNodeRestTest/testDeleteMasterNode/ > The test verifies that the remote view of the other nodes in the group is > populated. In this case the test failed because the node's join time is > recorded as zero. > {noformat} > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode > Failing for the past 1 build (Since Failed#2122 ) > Took 10 sec. > add description > Error Message > Node node2 has unexpected joinTime 0 > Stacktrace > junit.framework.AssertionFailedError: Node node2 has unexpected joinTime 0 > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodeData(BDBHAVirtualHostNodeRestTest.java:412) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodes(BDBHAVirtualHostNodeRestTest.java:397) > at > org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode(BDBHAVirtualHostNodeRestTest.java:206) > {noformat} > There were no further errors in the logs. -- 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