[PROTON-1661] Incomplete name comparision in transport.c pn_find_link()

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: proton-0.11.1, proton-c-0.17.0
• Fix Version/s: proton-c-0.18.0
• Component/s: proton-c
• Environment: RedHat EL 5 & 7
• Assignee: Unassigned
• Reporter: Nathan Campbell
• Created: 27/Oct/17 17:09
• Updated: 26/Mar/18 10:20
• Resolved: 07/Mar/18 17:19

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.

Issue Links

• duplicates: PROTON-1466 Container.create_receiver() does not create all receivers with certain names