Restore the non-direct frame fallback, cipher into a direct buffer - #877
Merged
Conversation
Defaulting the native cipher off in 5a1ca80 made JavaCipher the default, and it emitted a heap ByteBuf. That became the cumulation for Varint21FrameDecoder, whose Waterfall patch had dropped upstream's hasMemoryAddress() check, so frames were sliced straight out of a heap buffer and handed to the still-native zlib: java.lang.UnsupportedOperationException at io.netty.buffer.PooledHeapByteBuf.memoryAddress at net.md_5.bungee.jni.zlib.NativeZlib.process at net.md_5.bungee.compress.PacketDecompressor.decode Every online-mode player hit this on join. 0042 drops the hunk that removed upstream's fallback, restoring the invariant the native zlib depends on. 0068 then fixes the source: JavaCipher ciphers into a direct buffer, so frames stay zero-copy slices and the fallback is not on the hot path. 0067 covers both the decoder's fallback and the full cipher chain.
electronicboy
added a commit
that referenced
this pull request
Sep 9, 2026
Master ended up with three patches numbered 0067 and both halves of the same temporary protocol patch. #877 added 0067-Test-that-framed-packets-are-always- direct and 0068-Cipher-into-a-direct-buffer-in-JavaCipher, then #876 added 0067-Temp-26.3-pre-2-protocol-support against an older base, and #878 was meant to rename that to pre-3 but landed as an add, leaving the pre-2 file behind. applyPatches.sh globs the directory, so the two Temp patches both applied in lexicographic order and the second conflicted with the first: Applying: Temp: 26.3-pre-3 protocol support CONFLICT (content): Merge conflict in ProtocolConstants.java CONFLICT (content): Merge conflict in Protocol.java Drop the superseded pre-2 file and renumber pre-3 to 0069 so it sits after #877's patches. The patch content is byte for byte what #878 merged; only the number and the parent it was generated against change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Defaulting the native cipher off in 5a1ca80 made JavaCipher the default, and it emitted a heap ByteBuf. That became the cumulation for Varint21FrameDecoder, whose Waterfall patch had dropped upstream's hasMemoryAddress() check, so frames were sliced straight out of a heap buffer and handed to the still-native zlib:
java.lang.UnsupportedOperationException
at io.netty.buffer.PooledHeapByteBuf.memoryAddress
at net.md_5.bungee.jni.zlib.NativeZlib.process
at net.md_5.bungee.compress.PacketDecompressor.decode
Every online-mode player hit this on join.
0042 drops the hunk that removed upstream's fallback, restoring the invariant the native zlib depends on. 0068 then fixes the source: JavaCipher ciphers into a direct buffer, so frames stay zero-copy slices and the fallback is not on the hot path. 0067 covers both the decoder's fallback and the full cipher chain.