You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Justin Ross (JIRA)" <ji...@apache.org> on 2017/08/04 17:36:01 UTC
[jira] [Assigned] (PROTON-1516) [proton-c] Receiver crashes on
receving a multiframe delivery where the last frame is empty but with
more=false
[ https://issues.apache.org/jira/browse/PROTON-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Justin Ross reassigned PROTON-1516:
-----------------------------------
Assignee: Cliff Jansen (was: Andrew Stitcher)
> [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: 0.17.0
> Reporter: Ganesh Murthy
> Assignee: Cliff Jansen
> Labels: crash
> Fix For: proton-c-0.18.0
>
>
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org