[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-caciocavallo-dev
Subject:    Cacio is Leaking
From:       roman () kennke ! org (Roman Kennke)
Date:       2012-06-25 18:13:26
Message-ID: 4FE8AA46.1050607 () kennke ! org
[Download RAW message or body]

Am 25.06.2012 18:01, schrieb Roman Kennke:
> Hi Martin,
>
> Thanks for your continued efforts!> I finally managed to get Cacio
> running as the GUI backend for running
>> tests in our CI system.
>> The preliminary fixes for clipboard and screen resolution helped a
>> lot. The problems on Windows have been
>> resolved by using Metal UI instead of Native LAF.
>>
>> We discovered some more problems though:
>>   * We have one test where a visualizer with a rectangular grid is
>> tested for "box selection" gestures:
>>
>>   Point lup = new Point(10,1);
>>   Point rlp = new Point(50,21);
>>   robot.pressMouse(target, lup, MouseButton.LEFT_BUTTON);
>>   robot.moveMouse(target, rlp);
>>   robot.releaseMouseButtons();
>>
>>   This used to work with xvnc and generated mouse drag events that are
>> captured to select cells of the grid.
>>   These drag events are no longer generated.
>
> I think this is not implemented yet. I will do this in the next days.
>
>> * In some of our tests we open a Popup on a table, just to check
>> whether certain items are disabled.
>>   After this was done, the test did a click outside the popup to close
>> it.
>>   This pattern breaks the test with Cacio, as this popup keeps the
>> keyboard focus and later text input actions fail, because
>>   they are unable to obtain the focus.
>>
>
> Same here, I guess it's quite simply not implemented yet.
>
>> * The biggest issue last: Some of our tests are Memory Leak tests:
>>    0 They start an application
>>    1 load some dataset and
>>    2 perform some operations
>>    3 measure the allocated memory of the VM
>>    4 drop the dataset and repeat the cycle from step 1 (let's say 10
>> times or so)
>>
>>   The expectation is that the allocated Memory should stay somehow
>> stable in step 3.
>>   I must at least not grow proportionally with the number of cycles.
>>
>>   With Cacio as the backend we discovered a leak:
>>
>>   The allWindows list in java.awt.Window contains references to some
>> old Dialogs which are created in step 2 and
>>   definitely have been dispose()d. This should remove the references
>> but apparently it doesn't.
>
> Hmm, I just wrote what I think is a minimal testcase, and it doesn't
> show an obvious memory leak. Can you provide a testcase that shows the
> leak ?


Ok, I guess today is not my day. Of course, the leaky behaviour only 
shows when the window is actually made visible (because otherwise we 
don't even create a peer in the first place).


@RunWith(CacioFESTRunner.class)
public class TestLeakWindow {

     @Test
     public void test() {
         Window w = new Frame();
         w.setVisible(true);
         w.dispose();
         w = null;
         System.gc();
         try {
             Thread.sleep(1000);
         } catch (InterruptedException ex) {
             Thread.currentThread().interrupt();
         }
         Window[] windows = Window.getWindows();
         assertEquals(0, windows.length);
     }

}

I will debug and fix it asap.

Best regards,
Roman

[prev in list] [next in list] [prev in thread] [next in thread]