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

Bug 327779

Summary:

heap gets completely full by end of day; mouse & key response becomes 3-4 seconds

Product:

[Tools] CDT

Reporter:

Mike Reed <mnr102>

Component:

cdt-codan

Assignee:

Elena Laskavaia <elaskavaia.cdt>

Status:

RESOLVED FIXED

QA Contact:

Elena Laskavaia <elaskavaia.cdt>

Severity:

normal

Priority:

CC:

cdtdoug, malaperle

Version:

8.0

Target Milestone:

8.0

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
screenshot of heap analysis. Piechart of biggest objs.	none
heap analysis's shortest path view of large objs	none
heap analysis's accumulated objs view	none
Cash to cache	cdtdoug: iplog+

Description Mike Reed

2010-10-14 10:11:09 EDT

Build Identifier: CDT: 20100917-0705, Eclipse platform: 3.6.1.r361_v20100909-9g..etc

As I develop over the course of the day, my heap starts small (~500M), and over the course of the day, it blows up to use all of it (-Xmm 2500m.)  Eclipse becomes more & more unresponsive, by the end, it takes 3-4 seconds to respond to a mouse click or key-press.  I did a heap analysis (screen shots attached), and it appears to be codan code-analysis, and some weak-hash-map that is used inside it.

Reproducible: Always

Steps to Reproduce:
1. start eclipse.  it happens w/ both -Xmm 2048m, and also -Xmm 2500m
2. work all day, watch eclipse's response time to key presses & mouse clicks get worse (3-4 seconds)
3. note that I'm not building within Eclipse, so if Eclipse builds up some map of code-errors & doesn't erase them until the next make... well, I'm using external makefile & console to build, so that map will exist for ever.
4. Also note that restarting Eclipse gives me a small clean heap, so that's my current workaround.

Comment 1 Mike Reed

2010-10-14 10:13:26 EDT

Created attachment 180880 [details]
screenshot of heap analysis.  Piechart of biggest objs.

Comment 2 Mike Reed

2010-10-14 10:14:06 EDT

Created attachment 180881 [details]
heap analysis's shortest path view of large objs

Comment 3 Mike Reed

2010-10-14 10:14:42 EDT

Created attachment 180882 [details]
heap analysis's accumulated objs view

Comment 4 Mike Reed

2010-10-14 10:15:19 EDT

This is easily reproduce-able for me, so I'm happy to try things if a developer wants to get in touch.

Thx,
Mike

Comment 5 Marc-André Laperle

2010-10-15 01:25:37 EDT

Humm, still need to investigate some more but...

WeakHashMap<IASTFunctionDefinition, IControlFlowGraph> cfgmap

IControlFlowGraph can contain a node with strong reference to the same IASTFunctionDefinition as the key, for example through AST parents.

Mike, is it seen while always working on the same file?

Comment 6 Elena Laskavaia

2010-10-17 21:02:58 EDT

Thanks for analysis!
There is a bug where cache is not cleaned when new files are opened. 
Also "weak" part of the hash does not seems to work.
Anyway fixed. Also added paranoia mode (don't keep more than 20 elements)

As workaround disable all return related checkers

Comment 7 CDT Genie

2010-10-17 21:23:04 EDT

*** cdt cvs genie on behalf of elaskavaia ***
Bug 327779 - fixed cash items leakage

[*] AbstractIndexAstChecker.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.core.cxx/src/org/eclipse/cdt/codan/core/cxx/model/AbstractIndexAstChecker.java?root=Tools_Project&r1=1.12&r2=1.13
[*] CxxModelsCache.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.core.cxx/src/org/eclipse/cdt/codan/core/cxx/model/CxxModelsCache.java?root=Tools_Project&r1=1.4&r2=1.5

Comment 8 Marc-André Laperle

2010-10-17 23:00:03 EDT

Did you mean clearCache instead of clearCash?

Comment 9 Elena Laskavaia

2010-10-19 21:45:59 EDT

did I wrote Cash? I guess I typing what I thinking :)

Comment 10 Marc-André Laperle

2010-10-26 00:21:41 EDT

Created attachment 181691 [details]
Cash to cache

(In reply to comment #9)
> did I wrote Cash? I guess I typing what I thinking :)