[
https://issues.apache.org/jira/browse/PROTON-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032367#comment-14032367
]
Dominic Evans commented on PROTON-516:
--------------------------------------
This is actually a particularly nasty bug in proton 0.7 and earlier, because if
you've used proton-j, haven't explicitly set a max frame size, but have set
something else in the OpenType that occurs after max frame size in the list of
attributes. In that case you end up advertising the default max frame size of
4GB which causes a different behaviour than occurs if you don't advertise one
at all and was actually causing 64-bit proton clients to attempt to malloc >4GB
memory and was also seemingly causing 32-bit proton clients to SEGV as they
were hitting a 32-bit integer overflow in pn_buffer_ensure and attempting to
access an invalid pointer
> [proton-c] Dispatcher frame buffer set to peer's max frame size.
> ----------------------------------------------------------------
>
> Key: PROTON-516
> URL: https://issues.apache.org/jira/browse/PROTON-516
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.6
> Reporter: Ken Giusti
> Assignee: Andrew Stitcher
> Fix For: 0.8
>
>
> The size of the output frame buffer used by the Transport is set
> unconditionally to the max frame size advertised by the peer:
> In transport.c::int pn_do_open(pn_dispatcher_t *disp):
> pn_buffer_ensure( disp->frame, disp->remote_max_frame );
> This can potentially exhaust memory on small memory systems (eg, embedded
> devices). Instead, the output frame buffer should grow as needed based on
> the size of the payloads generated, limited by the remote_max_frame value.
> And, of course, pn_buffer_ensure + caller should handle realloc failures
> instead of ignoring them.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
