An internal error occurred during “Collecting garbage”

Hi John,

is it reproducable?  Does it occur with all projects and workspaces?  Can you send any further details/error logs?  This wiki has information on how to generate and find these.

http://processors.wiki.ti.com/index.php/Troubleshooting_CCS

What target and OS do you use?  Have you tried the latest version?

Best Regards,
Lisa

Lisa,

I think it would be difficult to reproduce, and it is very likely an eclipse problem. When this happened about 4 hours ago I had to repeatedly exit CCS and restart, yet it would recur in probably less than 15 minutes following restart. Happening with this at the same time is the slow response of CCS editor/indexer, although we actually have 8GB of RAM which at the time of the problem still have lots of free space, and that we are using SSD harddrivers. 

When I tried to reproduce it again, it however fails to show now and it is difficult for me to find out what has caused it.

John

Lisa,

Together with this I frequently see “updating windows” message. Though I don’t know what has prompted this windows, our experience with CCS is that whenever this “updating windows” message pops up CCS always responds slowly. So is it related with the “An internal error occurred during ‘Collecting garbage’” problem?

John

Hi John,

if you noticed a definite connection between the two then this is certainly possible that the windows update is doing something with CCS.

Aside from that we would need error logs or more definite information in order to be able to say more.  Are there logs you could send?

Best Regards,

Lisa

Lisa,

Just sent the file via conversation. Please check that.

Hi John,

I just got some initial feedback on the log from the team here helping me dig into this.   It seems like you are running out of system SWT handles. (created whenever some GUI component or window is opened)  What would help us continue debugging is to understand how you are using CCS.  Ie what windows do you have opened?  Do you close and re-open some multiple times?  (If so which ones) What GUI actions do you preform before seeing this problem/behaviour?

Best REgards,

Lisa

Lisa,

Thanks for looking into the problem.

I use either edit or debug view. In edit view I open project window, outline window, editor window, console window. In debug view I open debug window, console window, register window, variable window, expression window, diassembly window, memory viewer. However not all windows are opening at the same time, for example, disassembly and memory view share the same window using different tabs and at one time only one of them is on the foreground.

There are 50 or even more editor windows opening at the same time and I usually forgot to close the unused. In CCS4 this didn't cause any problem.

Is there any more info I need to provide?

John

Martin,

We have tried opening the heap view and observed it for several hours during normal use, but haven't found any indicative problem. Regarding using a new workspace, since the current workspace contains settings for many debugging projects we have created, using a new might entail updating settings for each of them so we just refrain from doing it. If the problem arises again we would just exit and restart CCS.

Thanks for your help.

John

Hi John,

I happened to read your question, and when Lisa mentioned running out of system handles it rang a bell for me: I used to have a problem in which opening a moderately large amount of windows would bring about strange phenomena such as windows being partially drawn or odd error messages. A simple registry tweak made the problem go away, so it might help you as well.

This is only relevant for Windows XP! From your screenshots it's not clear what you're running - this is not relevant to Vista/7.

In regedit, open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager.
In the SubSystems folder, open the "Windows" string and find the text inside: SharedSection=1024,3072,512 - change the values to: 1024,8192,2048 . Don't touch anything else!
In the Memory Management folder, change the "SessionViewSize" value from 30 to 40 (48 to 64 decimal).
Restart the system.

I hope this works for you. If it doesn't, just undo the changes. Good luck :)

-itay

We have suggested Itay's workaround in the past for CCS v3.3 and lower when debugging 7 or more CPU's at the same time. The issue was pretty reproducible and it was always very consistent. CCSv4.x and higher manage multi-core debugging differently and should not run into that particular issue. Based on John's machine specs it is probably a win7 64bit machine, where the registry is different and the workaround does not apply. 

Having said this looking at JVM heap might not be the only place that could consume memory. CCS is made up of GUI that is based on Eclipse. The front end is developed with java. However, significant portions of the backend like debugger and drivers are C++ based components, where memory leaks would not necessarily manifest in java heap. Thus taking a look with something like task manager and java heap monitor to determine whether leak is in C++ or java would be a very important piece of information to help narrow down the issue. However, interpreting memory consumption with application that uses JVM (like CCS) can be tricky. In the past when I tried to evaluate memory consumption with java heap monitor and task manager I observed that processes memory shows peak JVM heap utilization and while JVM heap might shrink through garbage collection, that memory is not freed up in the process (if it is freed up down the road, then it is not immediately obvious). 

Martin

Martin,

I have to confess that I know little about the garbage collection mechanism of Java and its performance.  Yesterday I tried to reply to Itay’s post but was interrupted by some network problem.  In our CCS the heap size almost always shows somewhere 90M and 120M and we seldom saw any large figure (or if we have missed).

I am just temporarily shelving the problem aside since I only need to restart CCS about twice a day, it doesn’t take very much time.

John