CCS/TMS320C28346: CCS V8 causes memory leak on host PC

Ken,

conhost.exe is the Windows Console Host. cmd.exe is the windows command prompt.

Both of these would be initiated with a project build and then closed after the build is complete.  Similarly I see them started and stopped during the launch of a debug session.  In both cases the processes are terminated so I don't see how they can be leaking.  Are you seeing the memory allocated to these processes growing over time?

That said I do see the amount of memory being used by Ccstudio.exe increasing with each debug launch.  For me it goes up about 2.5MB per launch.  It does this regardless of which plug-ins I have enabled/disabled in the startup and shutdown settings.

Regards,

John

The memory that is used when the CCS application is launched is not an issue. This memory gets cleaned up when the application is terminated. It's the memory that gets used everytime the cmd.exe and conhost.exe processes run. This memory never gets cleaned up and accumulates until all the available memory is used or the PC is restarted. 

I went back to CCS V5 and confirmed that I do see this leakage in V5 as well when building or debugging. The main difference, and the reason we never took notice when using V5, is that V8 has the two Windows processes running when it is launched (cmd.exe is cycling, starting and stopping, and conhost.exe is always running). So with V8 just sitting there doing nothing it is leaking memory causing the PC to tap out much quicker. In an attempt to isolate a specific CCS function that uses these processes I began disabling the Startup/Shutdown plugins. It seems more than one use these so I ended up disabling them all. This was a brute force tactic that successfully stopped the cmd.exe from cycling when CCS is launched but conhost.exe is still started and must be manually terminated. This stops the memory leak during periods when you are not building/debugging but this also causes some unwanted behavior when you do run the debugger.

So, it appears there is no way around the use of the leaky Windows processes needed for building and debugging, but why are these started during the launch of CSS V8 when they were not started during the launch of CCS V5? Not having these processes run outside of the building and debugging operations would go a long way to extending the amount of time before memory runs out.

Ken

Ken,

Products evolve over the years.  

Note that I tried out CCSv5.5 and I can see that both cmd.exe and conhost.exe are started and terminated during a build but not during a debug launch.

In v8.3.1 I can also see that a conhost.exe is started when I start CCS and stays running (no increasing of memory, stays at 2136K).  And a cmd.exe keeps running and disappearing.  When I launch a debug session I see a second conhost.exe started and then terminated.  Given the processes are terminated  any memory allocated by the process would be freed by Windows when the process is terminated.  

That said I did find some articles online about Windows leaking small amounts of memory when a process is terminated.  I downloaded RamMap and it may be that these 2 processes are leaving 24K of memory allocated each time they are run and closed.  I am going to restart my machine to clear up the list in RamMap to see if I can see this better.

If you want to trim down the plugins that are started the most I would do would be as per the capture below.  Sorry this capture is v9 on my Mac as that is where my forum window is open.

Regards,

John

You are definitely on to something here.  I think we have a workaround.

Shut down CCS

Go to <install dir>/ccsv8/eclipse/plugins

Move all the folders that start with com.ti.dvt to some location outside of CCS.  There are 28 of them

This will remove a bunch of features from CCS related to visualization.  Unfortunately it also will remove Resource Explorer.

I will see if I can find a smaller list to remove that will keep Resource Explorer working.

John

A smaller list to move that keeps resource explorer working:

• com.ti.dvt.analysis.*
• com.ti.dvt.codegenCoverage
• com.ti.dvt.energytrace
• com.ti.dvt.graph.visualization
• com.ti.dvt.ofssymbolmanager
• com.ti.dvt.profileanalysis
• com.ti.dvt.rcp
• com.ti.dvt.symbolmanager*
• com.ti.dvt.tidisassembly
• com.ti.ui*
• com.ti.uia*

Hello John,

Thank you for the response. I will need to have my IT support group move these files. I will let you know the results on my end once the files have been moved.

Best Regards,

Ken