• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 54 subscribers
  • Views 1326 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

"Internal Error - A stack overflow error has occurred." ... When compiling a static library project with CCS v11.2.0

Adam Hodgdon
Prodigy 80 points
Other Parts Discussed in Thread: CCSTUDIO

We have several static libraries that we've developed for our C2000 applications that were created and compile without issue in an older version of CCS (v8.0). When we try to compile these projects in v10.x and even the latest v11.2.0, we keep getting the above mentioned error. I thought this might have something to do with porting project settings from the v8.0 project to the newer versions of CCS, so I instead tried creating the project from scratch in the latest version of CCS. When I do this, the project will compile successfully the first time, but all subsequent attempts will cause the above mentioned error. I've tried this on two different machines (Windows 7 64-bit and Windows 10 Pro) with the same result. I've also tried several different libraries with difference source files and they all cause the same behavior. Here's a quick summary of the steps I go through to create the new project:

1) Create a new workspace folder and open in CCS v11.2.0

2) Select Project -> New CCS Project

3) Set target to "Generic C28xx Device", output type to "Static Library", and output format to "legacy COFF"

4) The only project properties that have been changed from the default settings are:

  a) C2000 Compiler -> Processor Options -> Specify floating point support = fpu32

  b) Added two additional paths under C2000 Compiler -> Include Options

  c) Specified a name/location for the generated .lib file under C2000 Archiver -> Basic Options

5) Copied two new folders with .h and .c source code into the new project folder

The first time I run "Build Project" on the new project, it will compile successfully without error. If I then try "Build Project" again, I get the "Internal Error" message box with the message "A stack overflow error has occurred. You are recommended to exit the workbench. Subsequent errors may happen and may terminate the workbench without warning. See the .log file for more details." If I make any code changes and try "Build Project" again, I keep getting this message. However, if I run "Rebuild Project" or "Clean Project" and then "Build Project", it will compile successfully without error.

I've looked through the generated .log file but can't make sense of it myself. Here's a snippet from file:

!MESSAGE An internal error occurred during: "Building project(s)".
!STACK 0
java.lang.StackOverflowError
at java.base/java.util.HashMap.putVal(Unknown Source)
at java.base/java.util.HashMap.put(Unknown Source)
at java.base/java.util.HashSet.add(Unknown Source)
at com.ti.ccstudio.project.core.internal.build.temp.BuildDescriptionManager.getSteps(BuildDescriptionManager.java:172)
at com.ti.ccstudio.project.core.internal.build.temp.BuildDescriptionManager.doAccept(BuildDescriptionManager.java:127)
at com.ti.ccstudio.project.core.internal.build.temp.BuildDescriptionManager.doAccept(BuildDescriptionManager.java:132)
at com.ti.ccstudio.project.core.internal.build.temp.BuildDescriptionManager.doAccept(BuildDescriptionManager.java:132)
at com.ti.ccstudio.project.core.internal.build.temp.BuildDescriptionManager.doAccept(BuildDescriptionManager.java:132)

I can provide the complete .log file if it helps.

The two main questions I have are: 1) Any idea why this is happening and how to make it not happen? 2) If I use "Rebuild Project", should I be concerned at all about the integrity of the generated .lib file?

Thanks

  • 0
    TI__Guru**** 436731 points

    Hello,

    Adam Hodgdon said:
    1) Any idea why this is happening and how to make it not happen?

    I'm unsure as to the cause. I cannot reproduce this issue.

    Can you share your actual project? You can zip up the whole project folder and attach it to this thread (or contact me via private E2E message if you do not wish to share publicly).

    Adam Hodgdon said:
    2) If I use "Rebuild Project", should I be concerned at all about the integrity of the generated .lib file?

    No. The only "issue" would be that a "rebuild project" is that it takes longer because it would clean and build everything again.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 80 points

    Thanks for the responses Ki. For #1, I'll send you the zipped up project in just a minute. For #2, the rebuild time is not an issue because these are small support libraries so the clean and build times are relatively short.

  • 0 in reply to Adam Hodgdon
    TI__Guru**** 436731 points

    I received the test case. Thank you. And I can reproduce the issue. I'll need to escalate this to engineering for further analysis.

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru**** 436731 points

    I am still waiting to hear back from engineering. However I did some experimenting on my own and I believe I found the root cause of the issue. It appears that if the output directory is a path inside the project folder or subfolder and not one of the build configuration subfolders, the error will occur.

    Example:

    ${PROJECT_ROOT}/lib/library.lib

    The above will fail

    If changed to say:

    ${PROJECT_ROOT}/Release/library.lib

    This will not fail.

    And any path outside the project folder will be fine.

    Based on what you mentioned earlier, looks like this worked in CCS 8.x?

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 80 points

    Interesting... Unfortunately we have lots of various support libraries that we've developed and added to over the years that all use that same common project folder structure. I can confirm that this wasn't an issue on earlier versions of CCS (4.x - 8.x) - I'm not sure about CCS 9.x as we jumped from 8.x to 10.x. For now it seems that using "Rebuild" instead of "Build" may be our easiest workaround until we either decide to change our project folder structures or if/when this might be resolved in a future version of CCS...

  • 0 in reply to Ki
    TI__Guru**** 436731 points

    Same error occurs with CCS 8.x for me.

    I suspect what is happenening is there is a conflict when the library is generated in the project (sub)folder but not in a build configuration subfolder. This is because all files in the project (sub)folder are considered part of the build. Thus the generated library will now be considered an file inputted to the linker, causing confusion. Hence this is not supported. However, CCS should not have that kind of stack overflow error.

  • 0 in reply to Ki
    TI__Guru**** 436731 points

    I tried with CCS 7.4 and the error does not occur. Hence it must be some issue introduced sometime in one of the CCS 8.x releases....

  • 0 in reply to Ki
    Prodigy 80 points

    I was using an early version of CCS 8 (8.0.0) when I noticed that this wasn't happening - I'm guessing you were using a later version of 8.x when you noticed that the same error occurred?

  • 0 in reply to Ki
    TI__Guru**** 436731 points

    In my example, I set the output path to:

    ../libtest.lib

    in 7.4, it can handle the scenario I alluded to earlier:

    Ki said:
    Thus the generated library will now be considered an file inputted to the linker, causing confusion.

    During the dependency scan it ignores the library (as it should)

    in 8.3.1 and greater, it simply hits an exception.

    I'll file a bug for this.

    ki

  • +1 in reply to Ki
    TI__Guru**** 436731 points
    Ki said:
    I'll file a bug for this.

    the tracking link for this bug is: https://sir.ext.ti.com/jira/browse/EXT_EP-10817

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 80 points

    Thanks again for the support. Given that I can use the "Rebuild" option to get around this for now, and now that you've filed a bug for this, I will consider this issue/discussion resolved.