Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 167141

Summary: Remaining memory leak in Windows Agent Controller w/ compatibility layer when executing tests
Product: z_Archived Reporter: Joe Toomey <jptoomey>
Component: TPTPAssignee: Igor Alelekov <igor.alelekov>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P1 CC: andrew.kaylor, dkhodges, karla.callaghan, kdsiefke, kmooney, samwai, steven.wasleski, xubing
Version: unspecifiedKeywords: plan
Target Milestone: ---   
Hardware: PC   
OS: Windows All   
Whiteboard:
Attachments:
Description Flags
A project with a JUnit test that demonstrates the leak
none
patch none

Description Joe Toomey CLA 2006-12-07 14:07:13 EST
Although we found and fixed many of the memory leak problems related to test execution in 4.3, this defect is to track a remaining leak that we did not fix.  The leak appears to be related to the use of binary custom commands over the control channel during the execution of the test.  The test project I am attaching has a test that (in addition to the normal binary custom command chatter on the control channel) sends 4000 binary custom commands to the workbench, and receives 4000 binary custom commands as responses.  I have tried varying both the size of each custom command and also the number of custom commands, and it appears that the leak is in proportion to the latter.  (i.e. it doesn't matter if the message itself is 8k or 8 bytes, the size of the leak stays the same.  If I increase the number of messages sent, the leak increases roughly proportionally.)

The leak appears to be (very roughly) about 1.7k per pair of binary custom commands, though this is an average, and may not be indicative of the actual cause of the leak.  I don't know if it matters whether the messages are sent from the agent or received by the agent.

Please let me know if I can help with your investigation of this defect.  Thanks!
Comment 1 Joe Toomey CLA 2006-12-07 14:08:58 EST
Created attachment 55269 [details]
A project with a JUnit test that demonstrates the leak
Comment 2 Joe Toomey CLA 2006-12-14 17:54:47 EST
Increasing priority to reflect consuming product's desire for a 4.2.2 fix.
Comment 3 Karla Callaghan CLA 2006-12-14 18:10:10 EST
Assigning to Igor and assigning target to 4.2.2 to indicate that is when it is desired.

Igor, Please prioritize this with your 4.2.2 work to see if it can actually be done in that timeframe.
Comment 4 Karla Callaghan CLA 2007-01-11 13:38:55 EST
Retarget to 4.4 as this work cannot be done in time for 4.2.2, for which the focus is to get things running on Vista.
Comment 5 Karla Callaghan CLA 2007-02-09 11:53:54 EST
Added effort estimate: 4 weeks
Comment 6 Igor Alelekov CLA 2007-04-18 07:44:49 EDT
Created attachment 64165 [details]
patch

Hi Samson,
Could you review and commit the patch?
It fixes memory leaks in XML parsing utils and removes Util.getCommands() function - it is not currently used but has memory access violation errors.
Comment 7 Samson Wai CLA 2007-04-18 13:44:54 EDT
Patch reviewed and committed to CVS 2007/04/18 13:46 EDT.

Igor, please mark this bug as fixed. Thanks.
Comment 8 Igor Alelekov CLA 2007-04-20 06:29:25 EDT
Hi Joe,
Could you test it with an AC build from 19.04 or later?
Comment 9 Igor Alelekov CLA 2007-04-26 09:15:01 EDT
Resolved
Comment 10 Joe Toomey CLA 2007-05-02 15:00:06 EDT
I finally had a chance to test the latest AC, and the binary custom command related leaks appear to be fixed.  This is a big improvement, and will be appreciated by our consuming products since they tend to run very long tests that have a fair amount of binary custom command traffic throughout the run of the test.

Additional testing shows that some per-launch leaks still remain, with the AC growing an average of ~1MB per test execution.  I built a stress test plugin in the 4.2 timeframe to test this scenario (for both stability and memory leaks), and it still works well.  I will open a new defect for fixing the per-launch leak and attach details on how to easily reproduce.  Thanks.