The validation is done at the highest point so if a sub message is what
goes over the limit it is caught at the outer message, thus reducing the
impact on the serialization code.
PiperOrigin-RevId: 511473008
The code that loads descriptors calls absl::CUnescape() to parse the escape sequences. Prior to this CL, we were not checking the return value of this call, effectively allowing the invalid data to be loaded.
If a user is compiling a .proto file, invalid escapes will be caught earlier in the compiler pipeline, and this check will be unnecessary. The only time this is an issue is when a descriptor has been constructed manually and is loaded into the runtime.
This bug manifested as an MSAN failure in a fuzz test, because in the error case absl::CUnescape() will return a string where some of the characters are uninitialized.
PiperOrigin-RevId: 511319279
Add a helper to put the logic in one place in the file.
Ensure all places that read messages also do the 2GB check for message size.
PiperOrigin-RevId: 511260874
Fix exit code on git commit which was preventing force-push and tagging from running even though these should work without a new commit. An empty commit is probably clearer anyways to show that sync has happened.
PiperOrigin-RevId: 511255365
Fix exit code on git commit which was preventing force-push and tagging from running even though these should work without a new commit. An empty commit is probably clearer anyways to show that sync has happened.
In 21.x, depending on "//python:well_known_types_py_pb2" provided a transitive dependency to `compiler/plugin.proto`. That dependency was incorrectly removed for 22.x.
In 22.x, we accidentally omitted stripping the "src" import prefix for plugin.proto. We stripped the prefix in 21.x and for all other well known types in 22.x.
This reverts that unintentional change.
If a change is committed while we're regenerating stale files, we should just bail and let the next job handle the refresh.
PiperOrigin-RevId: 510453613
Add the objects to the object graph and balance the retain count before
doing the parsing. This ensure if an error is hit (and a throw happens),
the object(s) won't be leaked.
Parsing will always mutate the graph, so yes this includes more mutations
in failure cases, but other fields could always be modified before the
bad data is encountered. But even then, that edge case *only* apples to api
users that are explicitly *merge* (-mergeFrom...), the majority of the calls
are to +parseFromData:error:, so the entire graph is released on failure.
PiperOrigin-RevId: 510417377
The last attempted (rolled back) resulted in changes in visible behavior:
- It consumed a recursion depth on the input stream (wrong)
- It resulted in different error codes for some malformed/truncated data.
PiperOrigin-RevId: 510415215
Unconditional update of isMutable causes data races for
LazyStringArrayList::EMPTY_LIST that is used as the default value
for protobuf fields.
Not writing to it unconditionally may also improve performance
by reducing contention for the presumably widely shared EMPTY_LIST object.
PiperOrigin-RevId: 510366298
Chocolatey doesn't support any caching, so we're moving back to downloading the exe directly. This issue is responsible for a 5-10% flake rate in our windows cmake builds
PiperOrigin-RevId: 510202223
This fixes some relatively harmless flakiness in our post-submit. If two commits are made within ~5 minutes of each other, the `git push` command will fail because the git workspace isn't up to date.
PiperOrigin-RevId: 510165977
Chocolatey doesn't support any caching, so we're moving back to downloading the exe directly. This issue is responsible for a 5-10% flake rate in our windows cmake builds
PiperOrigin-RevId: 510202223
This fixes some relatively harmless flakiness in our post-submit. If two commits are made within ~5 minutes of each other, the `git push` command will fail because the git workspace isn't up to date.
PiperOrigin-RevId: 510165977
Bazel has a 2 minute timeout for their internal `xcrun` call, which can be exceeded on our github runners about 5% of the time. This leads to flakes and opaque errors, but is a one-time cost. Subsequent xcruns finish in seconds, so we can just do an initial call w/o a timeout before running Bazel.
With this change our total flake rate drops from ~30% to nearly 0% for our full suite of tests
See https://github.com/bazelbuild/bazel/issues/17437 for background.
PiperOrigin-RevId: 509944178
Protobuf Team Bot
Joshua Haberman
Sandy Zhang
deannagarcia
Deanna Garcia
Martijn Vels
Protobuf Team Bot
Mike Kruskal
Jakob Buchgraber
Mike Kruskal