Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
| Dev |
|
| QA |
|
| Priority | Low |
| Complexity | Unknown |
| Component | Tools - Table Data Editor |
| Version | 14.0 |
Noticed this problem while working on ADS issue #8187. Below are steps to reproduce the problem:
(1) Launch ADS with -Xmx768M
(2) Create a test table with two columns: integer and longtext.
(3) Follow the similar way described in issue #8187 to insert two rows to the newly created table.
The size of each row is significant in order to reproduce this problem.
In my test case, the size of each row is about 10 MB.
(4) Close all of opened tabs and exit ADS.
(5) Restart ADS.
(6) In the schema tree, expand the tree to the table defined in (2).
(7) Right click the table node defined in (2) and select 'Edit Table Data (Top N)'.
(8) After 'Edit Table Data' dialog is displayed, make change in the second column for both rows.
(9) Click the 'Primary Key - ...' tab and check the Key column for the first row.
(10) Click the 'Preview SQL' tab.
(11) Click the 'trash can' icon displayed in the lower-right corner and note the value of 'Used memory:'.
(12) Click the first data row, then click the second data row, then click the 'trash can' icon.
The 10-MB data displayed in the 'Selected Cell Content' pane should change and the 'Used memory:' would remain the same.
(13) Repeat step (12) a few times, everything should work as expected.
(14) So far so good, now, here comes the problem when switching tabs:
(15) Click the 'Messages' tab, then click the 'trash can' icon; the 'Used memory:' pretty much remains the same.
(16) Click the 'Preview SQL' tab, then click the 'trash can' icon; the 'Used memory:' goes up.
(17) Repeat steps (15) and (16) a few times, you will run out of memory.
I also did some test before running out memory, some of memory allocated by step (16) never gets released even 'Edit Table Data' dialog is closed. I ran Eclipse Memory Analyzer Tool (MAT) and generated some reports (attached).
The third and the last three screenshots ( MAT-Problem-Suspect-[1-3-4-5]-Path-To-GC-Roots ) indicate that the DataObject associated to the "Selected Cell Content" JEditorPane is not released and this could happen if PaneFactory.closedPane() is not called for that component. Indeed, debug sessions underline that whenever the Preview SQL tab becomes visible, a new editor pane is instantiated ( PaneFactory.createNBEditorPane(pane, mime) gets called) but PaneFactory.closedPane() is never called on the previous instance; it is not called even if the Table Data Editor window is closed by the user ). You need to fix these missing calls (i.e. on tab focus change and on window close events).
The MAT-Problem-Suspect-2-Path-To-GC-Roots screenshot indicates that EditorFrame._editorPane and CTabbedPane.parent hold references to the DataTableModel. If these screenshots were obtained after the TableDataEditor was closed, then there is an issue, because these GUI components shouldn't be present on the Swing hierarchy anymore.
It seems that PaneFactory.closedPane(JEditorPane) is never used by ADS. I will look into this.
It seems that PaneFactory.closedPane(JEditorPane) is never used by ADS. I will look into this.
ADS already calls this API method in some cases (e.g. open a new Query Analyzer Window then close it => PaneFactory.closedPane() gets called).
ADS already calls this API method in some cases (e.g. open a new Query Analyzer Window then close it => PaneFactory.closedPane() gets called).
Yes, you are correct. PaneFactory.closedPane() is called in certain cases and I found it.
Yes, you are correct. PaneFactory.closedPane() is called in certain cases and I found it.
SVN r31378 - most of leaks should have been fixed
Using r31378, I was able to repeat step 15 and step 16 N times without any problem where N is 20+. While step 16 is executed, the 'Used memory:' is usually in the range 400-600 MB. After repeating N times, I close the Table Data Editor and a dialog is prompted, there are 2 scenarios: click the 'Discard' button or click the 'Save' button.
Discard scenario: after Discard button is clicked, click the GC icon a few times, the 'Used memory:' goes down to ~310 MB (D-A). Wait for about 7-10 minutes, click the GC icon again, 5-6 times, the 'Used memory:' goes down to ~250 MB (D-B). Now, open a Query Analyzer panel, then click the GC icon 5-6 times, the 'Used memory:' is reduced to ~85 MB (D-C).
Save scenario: after Save button is clicked, click the GC icon a few times, the 'Used memory:' goes down to ~470 MB (S-A). Wait for about 7-10 minutes, click the GC icon again, 5-6 times, the 'Used memory:' goes down to ~350 MB (S-B). Now, open a Query Analyzer panel, then click the GC icon 5-6 times, the 'Used memory:' is reduced to ~85 MB (S-C).
The difference of the used memory between D-A and D-B (S-A and S-B) is the memory referenced by soft references (per Eclipse MAT).
The difference between D-B and D-C (S-B and S-C) are not reported as soft references by Eclipse MAT. However, those memory is freed up most of time when a new Query Panel (or a Fluid Shell, or a Table Data Editor, etc.) is opened. While working on this issue, I did many tests and there were a few times that the difference between D-B and D-C is not garbage-collected even a new Query Analyzer is opened. I tried to address this with different approaches but not very successful. For the time being, I will take a note on this but probably will not spend more time on this. When testing r31378, please make sure the used memory does get freed up by D-C and S-C most of times.
SVN r31378 - most of leaks should have been fixed
Using r31378, I was able to repeat step 15 and step 16 N times without any problem where N is 20+. While step 16 is executed, the 'Used memory:' is usually in the range 400-600 MB. After repeating N times, I close the Table Data Editor and a dialog is prompted, there are 2 scenarios: click the 'Discard' button or click the 'Save' button.
Discard scenario: after Discard button is clicked, click the GC icon a few times, the 'Used memory:' goes down to ~310 MB (D-A). Wait for about 7-10 minutes, click the GC icon again, 5-6 times, the 'Used memory:' goes down to ~250 MB (D-B). Now, open a Query Analyzer panel, then click the GC icon 5-6 times, the 'Used memory:' is reduced to ~85 MB (D-C).
Save scenario: after Save button is clicked, click the GC icon a few times, the 'Used memory:' goes down to ~470 MB (S-A). Wait for about 7-10 minutes, click the GC icon again, 5-6 times, the 'Used memory:' goes down to ~350 MB (S-B). Now, open a Query Analyzer panel, then click the GC icon 5-6 times, the 'Used memory:' is reduced to ~85 MB (S-C).
The difference of the used memory between D-A and D-B (S-A and S-B) is the memory referenced by soft references (per Eclipse MAT).
The difference between D-B and D-C (S-B and S-C) are not reported as soft references by Eclipse MAT. However, those memory is freed up most of time when a new Query Panel (or a Fluid Shell, or a Table Data Editor, etc.) is opened. While working on this issue, I did many tests and there were a few times that the difference between D-B and D-C is not garbage-collected even a new Query Analyzer is opened. I tried to address this with different approaches but not very successful. For the time being, I will take a note on this but probably will not spend more time on this. When testing r31378, please make sure the used memory does get freed up by D-C and S-C most of times.
SVN r31706 - reset SWING related variables in EDT; otherwise, might cause NPE in EDT.
SVN r31706 - reset SWING related variables in EDT; otherwise, might cause NPE in EDT.
Issue #8320 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build trunk/31378 |
| No time estimate |
1 issue link |
relates to #8187
Issue #8187Out of memory error |
The third and the last three screenshots ( MAT-Problem-Suspect-[1-3-4-5]-Path-To-GC-Roots ) indicate that the DataObject associated to the "Selected Cell Content" JEditorPane is not released and this could happen if
PaneFactory.closedPane()is not called for that component. Indeed, debug sessions underline that whenever the Preview SQL tab becomes visible, a new editor pane is instantiated (PaneFactory.createNBEditorPane(pane, mime)gets called) butPaneFactory.closedPane()is never called on the previous instance; it is not called even if the Table Data Editor window is closed by the user ). You need to fix these missing calls (i.e. on tab focus change and on window close events).The MAT-Problem-Suspect-2-Path-To-GC-Roots screenshot indicates that
EditorFrame._editorPaneandCTabbedPane.parenthold references to theDataTableModel. If these screenshots were obtained after the TableDataEditor was closed, then there is an issue, because these GUI components shouldn't be present on the Swing hierarchy anymore.