This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS command line build is extremely slow when executed within docker container

Other Parts Discussed in Thread: CCSTUDIO

There seem to be a problem with com.ti.ccstudio.apps.projectBuild application when executed within docker container. The eclipse process gets stuck for a couple of minutes (using 100% of a single CPU) after makefiles generation step but before the actual compilation. Effectively, firmware builds on docker container are unacceptably slower than direct host builds. It makes the Continuous Integration painful.

When the stuck process is forcefully terminated and then gmake is invoked manually - firmware builds correctly.

Example:

Host:

$ time /opt/ccstudio/ccs/eclipse/eclipse -noSplash -data ccs_workspace -application com.ti.ccstudio.apps.projectBuild -ccs.projects foo

...

32.40s user 1.73s system 441% cpu 7.729 total

Docker container:

$ time /opt/ccstudio/ccs/eclipse/eclipse -noSplash -data ccs_workspace -application com.ti.ccstudio.apps.projectBuild -ccs.projects foo

...

real 3m43.434s
user 1m51.703s
sys 2m22.361s

Technical details:

Tested on:

OS: Manjaro, Fedora 38, Fedora 39

CCS versions: 12.3, 12.6

Stuck process:

/opt/ti/ccs/eclipse/jre/bin/java -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true -Xms40m -Xmx512m --add-modules=ALL-SYSTEM -jar /opt/ti/ccs/eclipse//plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar -os linux -ws gtk -arch x86_64 -launcher /opt/ti/ccs/eclipse/eclipse -name Eclipse --launcher.library /opt/ti/ccs/eclipse//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.400.v20211117-0650/eclipse_11600.so -startup /opt/ti/ccs/eclipse//plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar --launcher.appendVmargs -exitdata 1 -data ccs_workspace -application com.ti.ccstudio.apps.projectBuild -ccs.projects foo -vm /opt/ti/ccs/eclipse/jre/bin/java -vmargs -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true -Xms40m -Xmx512m --add-modules=ALL-SYSTEM -jar /opt/ti/ccs/eclipse//plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar

Build stdout when the process gets stuck:

...

================================================================================
Pre processing...


================================================================================
Building...


**** Build of configuration Debug for project foo ****

/opt/ti/ccs/utils/bin/gmake -k -j 12 all -O  


  • Hello,

    Please note that docker environments are not officially supported environments. However, other customers have successfully used them with CCS.

    With that said:

    OS: Manjaro, Fedora 38, Fedora 39

    None of the above Linux distros are officially supported by CCS. Only Ubuntu 22.04 and 20.04 are officially supported by CCS 12.x. Other distros many work (and they often do), however we are unable to provide much support for them. I have not heard of slow build issues in docker for those environments.

    Are all projects impacted similarly? If you disable parallel builds, do you still see the issue?

    Thanks

    ki 

  • Hi Ki!,

    I have just tested that on Ubuntu 22.04 docker image (https://github.com/michalkaptur/ccs_docker) and the issue is still there: build process gets stuck somewhere between Makefiles generation and the actual compilation. Local native build takes <20s, Ubuntu 22.04 docker build takes >2 minutes.

    Disabling parallel builds with "-ccs.buildCommandFlags -j1" didn't change much, build execution was just slightly longer due to sequential compilation.

    I have tried to build just two different projects and the issue is observed in both of them.

    Regards,

    Michał Kaptur

  • Thanks for trying out Ubuntu. I'll check with some engineers here who use docker to see if they have noticed any such issues.