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