Hi Sacheta, I cannot tell much about this as I have a limited understanding about your case but you can check how Flatbuffer is integrated into gRPC. Flatbuffer provides its SerializationTraits for gRPC so that gRPC and [de]serialize their messages. (See https://github.com/google/flatbuffers/blob/ca73ff34b76a26ab51413074191f8010b3228daf/include/flatbuffers/grpc.h#L261-L295)
Regards, Esun. On Thursday, July 10, 2025 at 7:47:11 AM UTC-7 Sacheta Saini wrote: > Hi Team, > > I'm Sacheta, one of the developers working on the labview-grpc > <https://github.com/ni/grpc-labview> project. > > > > *Little Background:* > > LabVIEW is a graphical programming environment, primarily used for testing > and measurement applications. > > Since LabVIEW is not officially supported by Google for gRPC, we’ve > implemented a custom integration. As part of our efforts to upgrade the > gRPC submodule from v1.62.0 to v1.70.0, we encountered a critical crash > related to protobuf. > > *Summary of the Issue:* > > We use a custom class, LVMessage, which manually inherits from > google::protobuf::Message to handle marshalling between LabVIEW data > types and protobuf messages. This approach worked fine until we upgraded to > gRPC v1.70.0 (protobuf v3.29.0). The method GetClassData() has now been > made pure virtual and is expected to return metadata typically generated by > protoc. > > Our initial workaround was to override GetClassData() and return nullptr. > However, this results in a crash because the protobuf runtime > unconditionally accesses the returned value. > > On examining protoc-generated code, we realized GetClassData() returns a > complex internal structure (ClassData), which is tightly coupled with > protoc output and not feasible to recreate manually. > > We reached out to the Google team (see thread > <https://groups.google.com/g/protobuf/c/Ej4RAPkwKsY/m/OgEiNuC4AAAJ>), and > they confirmed that manually inheriting from Message or MessageLite is > not the intended usage. Instead, they suggested using a custom Codec with > gRPC to implement our own serialization/deserialization logic independently. > > *Why We Avoid protoc:* > > We intentionally avoid using protoc because it generates platform-specific > C++ code. Since LabVIEW is designed to be platform-independent, introducing > native binaries would compromise this goal. > > *Next Steps:* > > It appears we will need to re-architect our integration and move toward a > custom Codec approach. However, if anyone here has: > > - Knowledge of alternative approaches > - Knowledge of implementing a custom Codec in gRPC > - Successfully handled a similar use case before > > —we’d greatly appreciate your guidance or suggestions. > > Thanks in advance! > > Sacheta > -- You received this message because you are subscribed to the Google Groups "grpc.io" 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/grpc-io/e44bea85-56e3-4062-a268-547f259bdb27n%40googlegroups.com.
