Bug 45395 - MsgAjp dump method does not dump packet when being written
Summary: MsgAjp dump method does not dump packet when being written
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 minor (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Keywords: ErrorMessage
Depends on:
Reported: 2008-07-14 17:00 UTC by Steve Parr
Modified: 2011-10-25 18:48 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Steve Parr 2008-07-14 17:00:52 UTC
In org.apache.jk.common.MsgAjp, the dump method is a debug utility to provide debug output of the buffer contents when errors occur.  It uses the "len" variable to control this output.  This probably works fine in the case of a packet read.  But in the case of a packet write, the "len" variable is not set until then "end" method is called once the packet is complete.  In the case of an error during the generation of the packet to be written (such as a buffer overflow in our case), the code such as cpBytes calls "dump" to display the contents of the buffer.  Since "end" has not been called, "len" still equals 4 and so only the first 8 bytes of the buffer are dumped followed by blank hex lines for the rest of the buffer up to the pos/max limit.  Obviously, this would be more useful if the "len" was ignored and "pos" was used instead.  Or "cpBytes" could call the "end" method before calling "dump" to set the "len" value.  I'm sure there are a couple of ways to fix this and I am not familiar enough with the code to pick the best fix.
Comment 1 Rainer Jung 2011-10-25 18:48:04 UTC
I don't understand your explanation.

The output would contain the bigger of len+4 and pos limited to 1000 bytes. So if pos were bigger than 8, you would see more characters. It is more likely, that cpBytes() had the problem, that the packet was empty, but more data than would fit into it were supposed to be copied in (something like that).

Feel free to reopen, if you can provide additional evidence what to improve here.