-
Notifications
You must be signed in to change notification settings - Fork 810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory corruption/panic on Clone/Merge of nonnullable repeated field #568
Comments
Hi. Thanks. I did take a look and your example/test looks good. I did noticed an older case related to I think the We can recommend using this library in the meantime: |
Due to a seg fault issue with the gogo protobuf library [gogo/protobuf#568], non nullable repeated fields in a proto will cause proto.Merge(dst, src) to panic. The nullable field setting was first added by @kyessenov when he was re-organizing the protos. Unfortunately, people have been copy pasting it across several areas in the Envoy proto. To keep the impact radius to a minimum, I have updated only the fields that are currently causing the segfault (in go-control-plane) for us. Its also partly against proto principles. You should be able to determine if a field is set or not. This non-nullable setting in gogo will insist on initializing the field to default values. Risk Level: to go control plane users Signed-off-by: Shriram Rajagopalan <rshriram@tetrate.io>
Due to a seg fault issue with the gogo protobuf library [gogo/protobuf#568], non nullable repeated fields in a proto will cause proto.Merge(dst, src) to panic. The nullable field setting was first added by @kyessenov when he was re-organizing the protos. Unfortunately, people have been copy pasting it across several areas in the Envoy proto. To keep the impact radius to a minimum, I have updated only the fields that are currently causing the segfault (in go-control-plane) for us. Its also partly against proto principles. You should be able to determine if a field is set or not. This non-nullable setting in gogo will insist on initializing the field to default values. Risk Level: to go control plane users Signed-off-by: Shriram Rajagopalan <rshriram@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ b22d2b5cf09f779962cfedaaab24969f384cbc48
Apparently reflection-based logic for merging protobuf messages misbehaves if it sees repeated non-nullable message field.
We've noticed it due to
proto.Clone(message)
returning shallow copy of the message, however while trying to get smaller example similar use case panics, which potentially points to the same cause.Example:
Test:
Panic:
The text was updated successfully, but these errors were encountered: