qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominic Evans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PROTON-516) [proton-c] Dispatcher frame buffer set to peer's max frame size.
Date Mon, 16 Jun 2014 11:57:02 GMT

    [ 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)

Mime
View raw message