[jira] [Commented] (MESOS-10110) Libprocess ignores most protobuf (de)serialisation failure cases.

["Charles Natali (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077633#comment-17077633 ] 

Charles Natali commented on MESOS-10110:
----------------------------------------

Hey.

 

It's probably my fault - I just created another account - this one, "cf.natali".

That's because my previous account "charle" obviously contained a typo and also didn't match the  username I used for the [https://reviews.apache.org/] and apparently Jira doesn't support chaning usernames.

 

Hope I didn't make too much of a mess!

> Libprocess ignores most protobuf (de)serialisation failure cases.
> -----------------------------------------------------------------
>
>                 Key: MESOS-10110
>                 URL: https://issues.apache.org/jira/browse/MESOS-10110
>             Project: Mesos
>          Issue Type: Bug
>          Components: libprocess
>            Reporter: Charles
>            Priority: Major
>
> Before the code didn't check at all the return value of
>  {{Message::SerializeToString}}, which can fail for various reasons,
>  e.g. out-of-memory, message too large, or invalid UTF-8 string.
>  Also, the way deserialisation was checked for error using
>  {{Message::IsInitialized}} doesn't detect errors such as the above,
>  we need to check {{Message::ParseFromString}} return value.
> {{}}
> We noticed this at work because our custom executor had a bug causing it to send invalid/non-UTF8 {{mesos.TaskID}}, but it was successfully serialised by the executor (driver), and deserialised by the framework, which was blowing it to blow up at later point far from the original source of the problem.
> More generally we want to catch such invalid messages - which can happen for a variety of reasons - as early as possible.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)