db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-865) Under SanityManager/debug control, pre-fill DDMWriter buffers with garbage to expose memory corruption errors
Date Tue, 24 Jan 2006 18:10:10 GMT
Under SanityManager/debug control, pre-fill DDMWriter buffers with garbage to expose memory
corruption errors

         Key: DERBY-865
         URL: http://issues.apache.org/jira/browse/DERBY-865
     Project: Derby
        Type: Improvement
  Components: Network Server  
    Reporter: Bryan Pendleton
    Priority: Minor

DDMWriter uses a byte array to manage a memory buffer of formatted, but not yet sent, network

The behavior of this byte array is that it automatically expands to accomodate the requests
that are given to it, but does not shrink. When the byte array is first expanded to a certain
size, Java provides 0x00 byte values for the new bytes automatically, but when the buffer
is later re-used, the bytes have whatever value they previously had.

When a bug should exist in the code, such as the off-by-one bug described in DERBY-125, the
bytes in the byte array may be used without being set. Analysis of DERBY-125 was complicated
because the already-existing value in the buffer turned out to be 0x00, which is a very common
value in DSS message buffers, and hence the bug was hidden for a long time because the value
turned out to be correct, accidentally.

Exposing and diagnosing such bugs would be much easier if the buffer's contents were automatically
set to some non-zero, unusual value, which would be less likely to be accidentally correct.

This should be as easy as just dropping a few lines of code into DDMWriter.ensureLength(),
however, since this could have a significant performance impact, the code should be written
carefully so that the performance is reasonable. One way to do this would be to make the code
conditional, and only perform the memory pre-setting if the source tree has been specially
built with the SanityManager enabled, or if debug flags are set to true, or some such configuration.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message