Bugzilla

From one of the Google engineers who works on protobuf:
> It looks like we recently started relying on the lower 3 bits of the pointer (see the TaggedStringPtr class) as tags, so I believe the 8-byte alignment is required to ensure that those bits are available for our use. If the 32-bit builds are not achieving the 8-byte alignment for some reason then that would explain the problem.

I asked about possibly not using arenas on affected platforms (from the docs, they're not mandatory):
> That's true that you could avoid using arenas on the affected platforms, but this might be tricky depending on how your code is written. A heap-allocated proto must be deleted, but an arena-allocated one must not be deleted (since the arena owns the memory). Internally we use an ArenaSafeUniquePtr class to wrap the pointer and destroy it in the right way based on whether it's arena-allocated or not, but I don't think we ever open sourced this.

Seems like a lot of possibly complexity for a Tier 2 platform :\. Is there any way we can force 8-byte alignment for protobuf's arenas even if that isn't guaranteed to be the case the rest of the time?

From one of the Google engineers who works on protobuf:
> It looks like we recently started relying on the lower 3 bits of the pointer (see the TaggedStringPtr class) as tags, so I believe the 8-byte alignment is required to ensure that those bits are available for our use. If the 32-bit builds are not achieving the 8-byte alignment for some reason then that would explain the problem.

I asked about possibly not using arenas on affected platforms (from the docs, they're not mandatory):
> That's true that you could avoid using arenas on the affected platforms, but this might be tricky depending on how your code is written. A heap-allocated proto must be deleted, but an arena-allocated one must not be deleted (since the arena owns the memory). Internally we use an ArenaSafeUniquePtr class to wrap the pointer and destroy it in the right way based on whether it's arena-allocated or not, but I don't think we ever open sourced this.

Seems like a lot of possible complexity for a Tier 2 platform :\. Is there any way we can force 8-byte alignment for protobuf's arenas even if that isn't guaranteed to be the case the rest of the time?

From one of the Google engineers who works on protobuf:
> It looks like we recently started relying on the lower 3 bits of the pointer (see the TaggedStringPtr class) as tags, so I believe the 8-byte alignment is required to ensure that those bits are available for our use. If the 32-bit builds are not achieving the 8-byte alignment for some reason then that would explain the problem.

I asked about possibly not using arenas on affected platforms (from the docs, they're not mandatory):
> That's true that you could avoid using arenas on the affected platforms, but this might be tricky depending on how your code is written. A heap-allocated proto must be deleted, but an arena-allocated one must not be deleted (since the arena owns the memory). Internally we use an ArenaSafeUniquePtr class to wrap the pointer and destroy it in the right way based on whether it's arena-allocated or not, but I don't think we ever open sourced this.

Seems like a lot of possible complexity for a Tier 2 platform. Is there any way we can force 8-byte alignment for protobuf's arenas even if that isn't guaranteed to be the case the rest of the time?