Shared memory leak on client/server database connections gives errors 14394,6495,915

Shared memory leak on Client/Server database connections.
Errors 14394 start appearing in the database lg file after many connect disconnects.
Database forces Abnormal shutdown with error 6495.

Monitoring shared-memory through promon shows ~ 560 KB memory lost over 24 hour period.
Each client/server connect and disconnect results in 168 byte of free shared memory not being released
Database has a high connect/disconnect rate
There are no Lock table overflows associated with the shared-memory depletion.

For each Client/Server connection to the database, 168 bytes are allocated from the shared-memory pool. In OpenEdge 10.1C this was deliberately left behind for re-use (on the next connection) instead of having to de-allocate and reallocate for every connection. Unfortunately, the database manager was over-writing the pointer to the 'left-behind' allocation from the client server connection causing the 168 bytes to be reallocated every time a new client server connection is made. This leak  eventually leads to exhausting the total allocated shared-memory, where the rate of attrition is 168 bytes per Client/server connect/disconnect (ie network connections). Once the shared memory is exhausted, any connection will fail allocating shared-memory (ie including self-service connections).

Upgrade to 10.1C03, 10.2A01 where the memory allocated for client/server connections still remains, but the memory will be reused anytime that connection is reused for other client/server connections before allocating more memory. Since the fix is on the server side, connecting with older clients will not have a negative impact.

If not possible to upgrade at this time use the following workaround:

1. Ensure that the current settings for shared-memory are sufficient for 'normal' operations. Specifically: -B, -Mxs, -shmsegsize and -maxAreas are all set to an environment-appropriate value rather than the defaults.

2. Monitor Shared-Memory either through promon > R&D > 1. Status Displays > 14. Shared Memory Segments

or the following ABL code:

FOR EACH _Segments:
        DISPLAY _Segment-ByteFree _Segment-BytesUsed.
END.

To avoid an Emergency shutdown of the database when "free memory" starts exhausting:

Example:
Seg Id---------Size---------used---------free
1   20971537 733454336 730158792 3295544
.. time ..
1   20971537 733454336 733355648 98688  (/168 = circa 580 connects remaining)

Increase -Mxs online with: 

$  proutil dbname -C increaseto -Mxs <value in KB>

NOTE:
0. The user running this cmd, must have the appropriate permissions to execute this utility. Please refer "OpenEdge Management: Database Administration - proutil increaseto qualifier"
1. All current promon connections must be stopped prior to running the 'proutil -C increaseto'
2. If existing connections have not yet connected to the shared memory or an additional shared-memory segment needs to be allocated to satisfy the 'proutil -C increaseto' argument, a message will appear listing these connections and prompt "yes/no" to wait.
Either: these connected users need to 'do something' to re-address the shared-memory segments or they need to be disconnected before the additional shared memory can be allocated.

Eventually the database will need to be shut down to release the memory associated with the leak (circa 168 bytes per connect/disconnect).