Build the EnforceDepthLimit performance requests without recursion, and stop tagging the performance suite.
The three EnforceDepthLimit tests in binary_recursion_limit_test.cc built a 20000-deep (10000 for MapStringKey) message object and called SerializeAsString() on it. ByteSizeLong(), the serializer and the destructor each recurse once per nesting level, which overflows the 8 MB stack under the sanitizers' larger frames in the test binary itself, before any testee is involved; that is the only reason every `<x>_performance_test` was tagged noasan/nomsan/notsan/noubsan/nodiorite by conformance_test().
The payloads are now built directly on the wire with the binary_wireformat.h helpers: each nesting level is the bytes before the level below it (the level's own fields and the tag of the field holding the next level) and the bytes after it (a group's end tag), and Nested() computes the sizes inside out, then appends the bytes outside in, with the length prefixes in between. That is O(total bytes) time, O(depth) heap and constant stack. The builders live in their own library, recursion_limit_payloads.{h,cc} (DeepMapPayload(), DeepMapStringKeyPayload(), DeepMessageSetPayload()), so that the suite file holds only the three tests. The bytes are identical to what the message objects serialized: recursion_limit_payloads_test builds all three payloads both ways at depths 1, 3 and 50 (two-byte length prefixes) and a depth-0 message set, and compares them, and the checked-in request goldens of migration:request_golden_test are unchanged.
With that fixed, conformance_test() has no reason left to tag `<x>_performance_test` differently from the other suites' tests: `_PERFORMANCE_TEST_TAGS` and the performance special case go away, every test gets exactly the caller's tags plus `conformance`, and the bzl_tests now assert that `<x>_performance_test` carries `conformance` but not `noasan` (as a representative of the dropped tag set), like the binary test. All 14 `<x>_performance_test` targets in the chain pass under asan, tsan and ubsan, and under msan except java and java_lite, whose callers tag them nomsan (Java doesn't support MSan); all 14 also pass on ARM (--cpu=arm), no slower than on x86. merged_runner_test and migration:request_golden_test drop their sanitizer and nodiorite tags too: the legacy binary suite lost its recursive --performance requests when the binary performance tests moved to gtest (binary_recursion_limit_test.cc), so nothing the merged runner links builds a deep payload recursively any more, and both pass under asan, msan, tsan and ubsan and on ARM.
PiperOrigin-RevId: 984539805
Copyright 2008 Google LLC
Protocol Buffers (a.k.a., protobuf) are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. You can learn more about it in protobuf's documentation.
This README file contains protobuf installation instructions. To install protobuf, you need to install the protocol compiler (used to compile .proto files) and the protobuf runtime for your chosen programming language.
Most users will find working from supported releases to be the easiest path.
If you choose to work from the head revision of the main branch your build will occasionally be broken by source-incompatible changes and insufficiently-tested (and therefore broken) behavior.
If you are using C++ or otherwise need to build protobuf from source as a part of your project, you should pin to a release commit on a release branch.
This is because even release branches can experience some instability in between release commits.
Protobuf supports Bzlmod with Bazel 8 +. Users should specify a dependency on protobuf in their MODULE.bazel file as follows.
bazel_dep(name = "protobuf", version = <VERSION>)
Users can optionally override the repo name, such as for compatibility with WORKSPACE.
bazel_dep(name = "protobuf", version = <VERSION>, repo_name = "com_google_protobuf")
Users can also add the following to their legacy WORKSPACE file.
Note that with the release of 30.x there are a few more load statements to properly set up rules_java and rules_python.
http_archive(
name = "com_google_protobuf",
strip_prefix = "protobuf-VERSION",
sha256 = ...,
url = ...,
)
load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()
load("@rules_java//java:rules_java_deps.bzl", "rules_java_dependencies")
rules_java_dependencies()
load("@rules_java//java:repositories.bzl", "rules_java_toolchains")
rules_java_toolchains()
load("@rules_python//python:repositories.bzl", "py_repositories")
py_repositories()
The protobuf compiler is written in C++. If you are using C++, please follow the C++ Installation Instructions to install protoc along with the C++ runtime.
For non-C++ users, the simplest way to install the protocol compiler is to download a pre-built binary from our GitHub release page.
In the downloads section of each release, you can find pre-built binaries in zip packages: protoc-$VERSION-$PLATFORM.zip. It contains the protoc binary as well as a set of standard .proto files distributed along with protobuf.
If you are looking for an old version that is not available in the release page, check out the Maven repository.
These pre-built binaries are only provided for released versions. If you want to use the github main version at HEAD, or you need to modify protobuf code, or you are using C++, it's recommended to build your own protoc binary from source.
If you would like to build protoc binary from source, see the C++ Installation Instructions.
Protobuf supports several different programming languages. For each programming language, you can find instructions in the corresponding source directory about how to install protobuf runtime for that specific language:
| Language | Source |
|---|---|
| C++ (include C++ runtime and protoc) | src |
| Java | java |
| Python | python |
| Objective-C | objectivec |
| C# | csharp |
| Ruby | ruby |
| Go | protocolbuffers/protobuf-go |
| PHP | php |
| Dart | dart-lang/protobuf |
| JavaScript | protocolbuffers/protobuf-javascript |
The best way to learn how to use protobuf is to follow the tutorials in our developer guide.
If you want to learn from code examples, take a look at the examples in the examples directory.
The complete documentation is available at the Protocol Buffers doc site.
Read about our version support policy to stay current on support timeframes for the language libraries.
To be alerted to upcoming changes in Protocol Buffers and connect with protobuf developers and users, join the Google Group.