There are possible buffer overflows in InternalOutputBuffer. I am attaching patches to dynamically flush buf when it is full. One way to trigger this exception is to add a header to the response which will be longer than maxHttpHeaderSize parameter (4K by default). Here is a typical stack trace: ArrayIndexOutOfBoundsException: 37522952 at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java(Inline at org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java(I at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java(Compil at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java(Compiled Code)) at org.apache.coyote.Response.action(Response.java(Inlined Compiled Code)) at org.apache.coyote.Response.sendHeaders(Response.java(Inlined Compiled Code)) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java(Compiled Code)) at org.apache.coyote.tomcat5.OutputBuffer.close(OutputBuffer.java(Compiled Code)) at org.apache.coyote.tomcat5.CoyoteResponse.finishResponse(CoyoteResponse.java(Compiled at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java(Compiled Code)) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java(Compiled Code) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Ht at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java(Compiled Code) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:568)
Created attachment 16465 [details] patch 1 out of 2
Created attachment 16466 [details] patch 2 out of 2
It's not a "buffer overflows": the HTTP request and response buffers are voluntarily limited in terms of size. So, sorry, -1.
The idea behind this patch is to enable large headers being sent without using up excessive amounts of memory. For example, our application sometimes sets a lot of cookies. Instead of always preallocation memory and sometimes running out of buffer space when we cannot predict the cookie sizes correctly, we send everything through the same buffer. Also, the patch avoids a hard to diagnose exception. If you look around the web, you will see that other people ran into this condition as well. I have not seen any of them successfully identify the problem much less point at maxHttpHeaderSize as a workaround. As to calling this condition a "buffer overflow", it would be that had this code not been written in Java. http://forums.atlassian.com/thread.jspa?threadID=6121&tstart=75 http://mail-archive.objectweb.org/ops-users/2005-06/msg00109.html http://swforum.sun.com/jive/thread.jspa?threadID=50844&messageID=185391
(In reply to comment #4) > As to calling this condition a "buffer overflow", it would be that > had this code not been written in Java. Yes, but this is Java, where "buffer overflow" does not exist. -1 and WONTFIX mean: no sorry. Please don't reopen the report.
Hi Remy, We do see this exception happening a lot on our production server. And by chasing down the code, System.arraycopy() are throwing the exceptions because it doesn't check the remaining size when appending more stuff into it. So I agree with Greg Steuck, just wondering why his fix never made into code base. Correct me if I am wrong. Yitao Guan yguan@ask.com