Resolution:
There was a defect identified in 6.8.1 and prior versions of the sscpp library in the TipcMsg::clone method which led to a memory leak. The workaround for this was to actually destroy the message twice.   In 6.8.2 this defect was addressed so that messages no longer need to be destroyed twice to properly free the memory. If you are calling TipcMsg::clone in your application, and you have implemented the workaround of destroying the cloned message twice then you will need to modify your application to remove the extra call to TipcMsg::destroy (or TipcMsgDestroy depending on how you coded the workaround).