https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
--- Comment #3 from Konstantin Kolinko <knst.koli...@gmail.com> --- (In reply to Fabian Günter from comment #0) > In 9.0.71 the code for MessageBytes#toBytes was changed to call the newly > introduced MessageBytes#toSimpleBytes method which incorrectly assumes that > byteC.getBuffer's retured array is a copy of the original request string Honestly, I do not follow your explanation. A byteC.getBuffer() call returns ByteChunk.buff. That is a byte[] array that is owned by that ByteChunk. The buff field in ByteChunk is initialized as null (by ByteChunk() constructor) or as a "new byte[initial]" (by other constructor calling allocate(..)). The only way that it may be changed to an externally created array is via a ByteChunk.setBytes(...) call. What call to ByteChunk.setBytes(...) passes such a shared array? > Every instance of MessageByte created early in the request processing > gets passed a reference to the same byte array > (which is documented in java.nio.ByteBuffer#array) I do not see such documentation. The javadoc of that method says "Returns the byte array that backs this buffer". Do we have several ByteBuffer instances that are backed by the same array? Do we have the same ByteBuffer instance reused somewhere? To be safe, I reviewed documentation for java.nio.charset.Charset.encode(...) method that is called by MessageBytes.toBytes(). It falls through to java.nio.charset.CharsetEncoder.encode(CharBuffer) which is documented as "Returns: A newly-allocated byte buffer". I know that CharsetEncoder class is not thread-safe, but no ByteBuffer sharing occurs here. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
