Hi,
Our CCS 5.2.0.00069 recently frequently run into the error started with the message
An internal error occurred during “Collecting garbage”.
Followed by the messages during ensuing operations all shown in the screenshot, and the memory consumed as shown by task manager is about 1.3G.
What happened and how can we solve it?
John
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.
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?
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
Just sent the file via conversation. Please check that.
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,
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?
There is definitely some sort of an issue that is being triggered. However, based on .logs it is not clear what might be causing it. 50 source files being opened should not cause that kind of memory utilization increase. Also, based on your comments you are using standard debug views, where I have not seen a very significant memory usage in the past. There might be higher memory needs when multiple target content .cfg files are opened, but it does not sound like this is the case. I was hoping that you could try to track and see which operations might be contributing to high memory utilization. Unfortunately, there is no easy way of doing this (other than having task manager open and keep checking it while working with CCS). The other thing that I was hoping you could keep an eye on is java heap utilization (you can enable this through Windows menu : Preferences , then click on General category and enable "Show heap status". Most of these are pretty intrusive on your workflow, but they should help to reproduce your issue on our end. Another option might be to setup a webex to see if you could reproduce this issue.
Garbage collection errors that you are seeing are a consequence of earlier issues rather than cause of them.
The only other short term suggestion that we could try is to see if data in workspace that CCS uses to keep state of various windows is causing issues. If you could try using new workspace directory and import your projects there. When CCS crashes, it is possible that state of that workspace metadata is in an inconsistent state and might be causing some unusual issues.
Thank you,Martin
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.
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
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.