You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When I use arena mode with cyber example code (cyber/examples/common_component_example), I found that reader will crash when the writer wrote the content field with a string that length greater than 16 (null terminator included).
Additional context
IMO, the reason it works fine with the content field's length less than 16 is because of std::string's SSO (Small String Optimization). When its length is less than a specific number (maybe 16B), the data will embedded in the std::string object. When the length exceeds, std::string will allocate memory on the heap to store it.
So, if string data is allocated on the heap instead of arena-managed memory, the address returned by std::string::data() will be on the writer's heap; to the reader, it is an illegal address.
This is a critical issue because it means any message including string or bytes could not transmit with arena mode on shared memory. The vast majority of protos include the string/bytes type fields.
Is it a known issue? Is there already any solution in the internal version of apollo?
Thanks!
The text was updated successfully, but these errors were encountered:
Describe the bug
When I use arena mode with cyber example code (
cyber/examples/common_component_example
), I found that reader will crash when the writer wrote thecontent
field with a string that length greater than 16 (null terminator included).To Reproduce
Proto:
Cyber config:
Writer:
Log:
Desktop:
Additional context
IMO, the reason it works fine with the
content
field's length less than 16 is because ofstd::string
's SSO (Small String Optimization). When its length is less than a specific number (maybe 16B), the data will embedded in thestd::string
object. When the length exceeds,std::string
will allocate memory on the heap to store it.So, if string data is allocated on the heap instead of arena-managed memory, the address returned by
std::string::data()
will be on the writer's heap; to the reader, it is an illegal address.Protobuf says the string fields store their data on the heap even when the containing message is on the arena. The same goes for
bytes
type field.This is a critical issue because it means any message including
string
orbytes
could not transmit with arena mode on shared memory. The vast majority of protos include the string/bytes type fields.Is it a known issue? Is there already any solution in the internal version of apollo?
Thanks!
The text was updated successfully, but these errors were encountered: