[
https://issues.apache.org/jira/browse/PROTON-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249174#comment-17249174
]
ASF subversion and git services commented on PROTON-1516:
---------------------------------------------------------
Commit 8c0e2099cc25c6fb9b53f25335898564a945f9f6 in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=8c0e209 ]
PROTON-1516: add tests for empty last frame in a streamed message
> [proton-c] Receiver crashes on receving a multiframe delivery where the last
> frame is empty but with more=false
> ---------------------------------------------------------------------------------------------------------------
>
> Key: PROTON-1516
> URL: https://issues.apache.org/jira/browse/PROTON-1516
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: proton-c-0.17.0
> Reporter: Ganesh Murthy
> Assignee: Clifford Jansen
> Priority: Major
> Labels: crash, framing
>
> I am running a network with two Apache Qpid Dispatch routers. A sender is
> attached to one of the routers and a receiver (simple_recv.py) is attached to
> the other router. The sender is sending very large multi-frame deliveries.
> The router, when it receives the message from the sender, keeps calling
> pn_link_send() several times as and when it receives more data and then
> finally calls pn_link_advance()
> In very rare cases the following frame pattern is sent out from the router to
> the receiver -
> {noformat}
> [0x7fc984034cc0]:2 -> @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"m\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (16344)
> "14150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345"...
> (truncated)
> [0x7fc984034cc0]:2 -> @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"m\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (4692)
> "13141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123"...
> (truncated)
> [0x7fc984034cc0]:2 -> @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"m\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=false]
> {noformat}
> Note that the last frame has no data in it but has more=false. I believe
> proton-c on the router is creating this frame sequence, meaning that the
> router code is not doing anything to create this frame sequence.
> On the receiver side, when this frame sequence is received, the receiver
> crashes as seen here -
> {noformat}
> [0x55da64b34470]:0 <- @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"r\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (16349)
> "21314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012"...
> (truncated)
> [0x55da64b34470]:0 <- @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"r\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (17880)
> "14150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345"...
> (truncated)
> [0x55da64b34470]:0 <- @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"r\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (2964)
> "67891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112131415012345678910111213141501234567891011121314150123456789101112"...
> (truncated)
> [0x55da64b34470]:0 <- @transfer(20) [handle=0, delivery-id=125,
> delivery-tag=b"r\x01\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=false]
> Traceback (most recent call last):
> File "simple_recv.py", line 56, in <module>
> Container(Recv(opts.address, opts.messages)).run()
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/reactor.py",
> line 133, in run
> while self.process(): pass
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/reactor.py",
> line 159, in process
> self._check_errors()
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/reactor.py",
> line 155, in _check_errors
> _compat.raise_(exc, value, tb)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/__init__.py",
> line 4050, in dispatch
> ev.dispatch(self.handler)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/__init__.py",
> line 3962, in dispatch
> self.dispatch(h, type)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/__init__.py",
> line 3959, in dispatch
> result = dispatch(handler, type.method, self)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/__init__.py",
> line 3837, in dispatch
> return m(*args)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/handlers.py",
> line 159, in on_delivery
> event.message = recv_msg(dlv)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/handlers.py",
> line 98, in recv_msg
> msg.decode(delivery.link.recv(delivery.pending))
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/__init__.py",
> line 1111, in decode
> self._check(pn_message_decode(self._msg, data))
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/__init__.py",
> line 822, in _check
> raise exc("[%s]: %s" % (err, pn_error_text(pn_message_error(self._msg))))
> proton.MessageException: [-4]: data error: not enough data to decode
> {noformat}
> The last frame being empty seems to be legal in AMQP 1.0.
> Neither should this frame sequence be generated by proton nor should the
> receiver crash when it sees this frame sequence.
> So there seems to be two bugs here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
