*Description:*
Hey team,
I'm *Sacheta*, one of the maintainers of the labview-grpc (
https://github.com/ni/grpc-labview) repository.
We're attempting to upgrade *gRPC from v1.62.0 to v1.70.0* and are
encountering a *blocking crash* due to changes in protobuf's code. We’d
really appreciate any guidance or workaround — otherwise, we may be forced
to *re-architect major parts of our integration* to support this upgrade.
------------------------------
*Problem Summary:*
During a unary gRPC call, we hit a *read access violation* in
MessageLite::AccessCachedSize(). The crash occurs because our override of
GetClassData() returns nullptr, and the protobuf runtime does not check for
null before dereferencing.
------------------------------
*Context:*
- LabVIEW is not a supported language for gRPC and doesn't allow us to
run protoc.
- To integrate with gRPC, we created a custom message class (LVMessage)
that manually *inherits from **google::protobuf::Message* and implements
our own serialization/parsing logic internally using a few methods from
protobuf::Message class.
- This worked fine in earlier protobuf versions, where GetClassData()
had a default implementation.
- But now when we tried upgrading to v1.70.0 (protobuf: v3.29.0),
GetClassData() seems to have become a pure *virtual method* required for
internal size/cache computations.
------------------------------
*What We Tried:*
- We initially provided a *minimal override* of GetClassData() that
returned nullptr. This compiled, but resulted in a crash during
serialization:
- *Error:*
- *Unhandled exception: read access
violation.MessageLite::GetClassData() returned nullptr.*
- *Callstack: *
textCopyEditMessageLite::AccessCachedSize()<-
MessageLite::GetCachedSize()<- SerializeWithCachedSizesToArray()<-
grpc::GenericSerialize()<- grpc::BlockingUnaryCallImpl()
- We then investigated how protoc-generated classes implement
GetClassData(), and discovered that they return a pointer to a ClassData
structure.
- However, this structure is:
- *Internally generated*
- Tightly coupled with the protoc output
- Contains metadata (field descriptors, cached size offsets, parsing
tables, etc.) that are *not publicly accessible* or replicable by hand
- Due to this, we found it *impractical and unsupported to construct a
valid **ClassData** manually*.
------------------------------
*Questions:*
1. If there’s a supported way to override or stub GetClassData() safely,
please advise.
2. Is it *supported* to manually subclass Message or MessageLite without
using protoc-generated code?
3. Are there *any alternatives* that allow basic serialization without
relying on ClassData?
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/protobuf/a3b5842a-a448-473e-9382-f12a57799e46n%40googlegroups.com.
