Mailing-List: contact dev-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@qpid.apache.org
Date: Fri, 27 Oct 2017 20:42:00 +0000 (UTC)
From: "Nathan Campbell (JIRA)" <jira@apache.org>
To: dev@qpid.apache.org
Message-ID: <JIRA.13112659.1509124191000.82350.1509136920103@Atlassian.JIRA>
In-Reply-To: <JIRA.13112659.1509124191000@Atlassian.JIRA>
References: <JIRA.13112659.1509124191000@Atlassian.JIRA> <JIRA.13112659.1509124191071@jira-lw-us.apache.org>
Subject: [jira] [Updated] (PROTON-1661) Incomplete name comparision in
 transport.c pn_find_link()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 27 Oct 2017 20:42:04 -0000


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

Nathan Campbell updated PROTON-1661:
------------------------------------
    Description: 
Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0

Problem:
Function "pn_find_link()" incorrectly returns a link when argument "name" matches first N characters of existing link.

i.e.:
1) QPID client creates receiver with address "amq.topic/fooBar":
   Broker will call function pn_find_link( ssn, name = "fooBar", true) which returns NULL as expected.  Link is initialized and receiver works as expected.

2) Some time later the same QPID client creates second receiver with address "amq.topic/foo":
  Broker will call function pn_find_link( ssn, name="foo", true) which incorrectly returns pointer to existing link.  Expected behavior is to return NULL so that link will (later) be initialized.

This is because if() starting on line 1268 of proton-c/src/core/transport.c only uses strncmp().
eg: "strncmp( "foo", "fooBar", 3) == 0"

That if() also needs to check +sizes of the names+ and only do "strncmp()" if:
"(name.size == strlen(pn_string_get(link->name)))"

Symptoms:
Qpid client blocks indefinitely on second ConnectionContext::createReceiver() waiting for link to be established.  Broker never does PN_LINK_INIT because it incorrectly believes link already exists, client is hung waiting for message back from broker.


  was:
Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0

Problem:
Function "pn_find_link()" incorrectly returns a link when argument "name" matches first N characters of existing link.

i.e.:
1) QPID client creates receiver with address "amq.topic/fooBar":
   Broker will call function pn_find_link( ssn, name = "fooBar", true) which returns NULL as expected.  Link is initialized and receiver works as expected.

2) Some time later QPID client creates second receiver with address "amq.topic/foo":
  Broker will call function pn_find_link( ssn, name="foo", true) which incorrectly returns pointer to existing link.  Expected behavior is to return NULL so that link will (later) be initialized.

This is because if() starting on line 1268 of proton-c/src/core/transport.c only uses strncmp().
eg: "strncmp( "foo", "fooBar", 3) == 0"

That if() also needs to check +sizes of the names+ and only do "strncmp()" if:
"(name.size == strlen(pn_string_get(link->name)))"

Symptoms:
Qpid client blocks indefinitely on second ConnectionContext::createReceiver() waiting for link to be established.  Broker never does PN_LINK_INIT because it incorrectly believes link already exists, client is hung waiting for message back from broker.


> Incomplete name comparision in transport.c pn_find_link()
> ---------------------------------------------------------
>
>                 Key: PROTON-1661
>                 URL: https://issues.apache.org/jira/browse/PROTON-1661
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.11.1, proton-c-0.17.0
>         Environment: RedHat EL 5 & 7
>            Reporter: Nathan Campbell
>
> Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0
> Problem:
> Function "pn_find_link()" incorrectly returns a link when argument "name" matches first N characters of existing link.
> i.e.:
> 1) QPID client creates receiver with address "amq.topic/fooBar":
>    Broker will call function pn_find_link( ssn, name = "fooBar", true) which returns NULL as expected.  Link is initialized and receiver works as expected.
> 2) Some time later the same QPID client creates second receiver with address "amq.topic/foo":
>   Broker will call function pn_find_link( ssn, name="foo", true) which incorrectly returns pointer to existing link.  Expected behavior is to return NULL so that link will (later) be initialized.
> This is because if() starting on line 1268 of proton-c/src/core/transport.c only uses strncmp().
> eg: "strncmp( "foo", "fooBar", 3) == 0"
> That if() also needs to check +sizes of the names+ and only do "strncmp()" if:
> "(name.size == strlen(pn_string_get(link->name)))"
> Symptoms:
> Qpid client blocks indefinitely on second ConnectionContext::createReceiver() waiting for link to be established.  Broker never does PN_LINK_INIT because it incorrectly believes link already exists, client is hung waiting for message back from broker.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org