[AXISCPP-339] Fix trivial memory leaks revealed by profiler tools

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.4 Final
• Fix Version/s: 1.6 Alpha
• Component/s: Basic Architecture
• Environment: All
• Assignee: Don Samisa Abeysinghe
• Reporter: Don Samisa Abeysinghe
• Created: 22/Dec/04 08:59
• Updated: 05/Apr/06 21:03
• Resolved: 05/Aug/05 13:35

Description

There are many trivial memory leaks revealed by memory profilers, leak trace tools.
Most of the problems are due to trivial memrory managment errors.

I will open a single Jira issue for this as it will be too much work to address all memeory leaks with seperate issues. Will use comments to report fixes. Please do the same if you fix any.

Issue Links

• depends upon: AXISCPP-342 There are too many leaks and possibilities for leaks in Param class and ParamValue class
• depends upon: AXISCPP-379 Memory leaks in case of exceptions, if that happnes after Call initialize and before Call unInitialize
• depends upon: AXISCPP-380 Some of the test client code deos not clean memory allocated for Stub object, input params and return values
• depends upon: AXISCPP-384 Memory leaks in XSD type classes - should define destructor to clean
• depends upon: AXISCPP-390 Memory leaks in case of SOAPFault
• depends upon: AXISCPP-391 Memory leaks due to non deallocation of g_traceEntrypoints in AxisTrace class
• is related to: AXISCPP-507 Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)