acpia430 segmentation fault

The file you attached is a .pp file generated by CCS and is not the one we are looking for. The one we need can be generated by following this page: http://processors.wiki.ti.com/index.php/Preprocess_Complex_Source_Code_for_Bug_Submissions

Please create this file and you can rename it to .txt or .cpp to attach it here.

You mentioned the internal error does not occur with the Debug build - could you let us know the options used for the Debug build, just for a comparison?

Hi AartiG,

1. The indicated procedure (even with comments off) discloses a big chunk of the code, which is something I cannot do.

2. Here is what I see when compiling the Debug version (the code runs from RAM and DMA is used):

Building file: ../ZLBus/zlbus.cpp
Invoking: MSP430 Compiler
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/bin/cl430" -vmspx --abi=eabi --code_model=large --data_model=large --near_data=none -Ooff --include_path="/home/swdev/ti/ccsv6/ccs_base/msp430/include" --include_path="/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include" --include_path="../../Start/Inc/" --advice:power="all" -g --gcc --define=__MSP430F5659__ --define=OS_LIBMODE_D --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --large_memory_model --printf_support=minimal --preproc_with_compile --preproc_dependency="ZLBus/zlbus.pp" --obj_directory="ZLBus" --exceptions  "../ZLBus/zlbus.cpp"
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/iosfwd", line 387: remark #1542-D: (ULP 12.1) Detected memcpy() and recommend using DMA instead if greater than 100 words being transferred
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/iosfwd", line 402: remark #1542-D: (ULP 12.1) Detected memcpy() and recommend using DMA instead if greater than 100 words being transferred
"../ZLBus/zlbus.hpp", line 87: remark #1527-D: (ULP 2.1) Detected SW delay loop using empty loop. Recommend using a timer module instead
"../ZLBus/../DMA/dma_drv.hpp", line 27: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
"../ZLBus/../DMA/dma_drv.hpp", line 28: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
"../ZLBus/zlbus.cpp", line 34: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
"../ZLBus/zlbus.cpp", line 46: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
"../ZLBus/zlbus.cpp", line 61: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
"../ZLBus/zlbus.cpp", line 69: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring", line 341: remark #1537-D: (ULP 9.1) Function parameter _Al (type "std::allocator<char>") is being passed by value and should be passed by reference using pointer
          detected during:
            instantiation of "std::_String_val<_Ty, _Alloc>::_String_val(std::_String_val<_Ty, _Alloc>::_Alty) [with _Ty=char, _Alloc=std::allocator<char>]" at line 405
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::basic_string(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 18 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/stdexcept"
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xmemory", line 145: remark #1535-D: (ULP 8.1) variable "_Count" is used as a constant. Recommend declaring variable as either 'static const' or 'const'
          detected during:
            instantiation of "std::size_t std::allocator<_Ty>::max_size() const [with _Ty=char]" at line 1243 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring"
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::size_type std::basic_string<_Elem, _Traits, _Ax>::max_size() const [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 1631 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring"
            instantiation of "bool std::basic_string<_Elem, _Traits, _Ax>::_Grow(std::basic_string<_Elem, _Traits, _Ax>::size_type, bool) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 701 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring"
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::_Myt &std::basic_string<_Elem, _Traits, _Ax>::assign(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &, std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 407 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring"
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::basic_string(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 18 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/stdexcept"
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring", line 1598: remark #1530-D: (ULP 5.1) Detected divide operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
          detected during:
            instantiation of "void std::basic_string<_Elem, _Traits, _Ax>::_Copy(std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 1634
            instantiation of "bool std::basic_string<_Elem, _Traits, _Ax>::_Grow(std::basic_string<_Elem, _Traits, _Ax>::size_type, bool) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 701
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::_Myt &std::basic_string<_Elem, _Traits, _Ax>::assign(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &, std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 407
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::basic_string(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 18 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/stdexcept"
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring", line 1599: remark #1530-D: (ULP 5.1) Detected divide operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
          detected during:
            instantiation of "void std::basic_string<_Elem, _Traits, _Ax>::_Copy(std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 1634
            instantiation of "bool std::basic_string<_Elem, _Traits, _Ax>::_Grow(std::basic_string<_Elem, _Traits, _Ax>::size_type, bool) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 701
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::_Myt &std::basic_string<_Elem, _Traits, _Ax>::assign(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &, std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 407
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::basic_string(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 18 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/stdexcept"
"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/xstring", line 1600: remark #1530-D: (ULP 5.1) Detected divide operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
          detected during:
            instantiation of "void std::basic_string<_Elem, _Traits, _Ax>::_Copy(std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 1634
            instantiation of "bool std::basic_string<_Elem, _Traits, _Ax>::_Grow(std::basic_string<_Elem, _Traits, _Ax>::size_type, bool) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 701
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::_Myt &std::basic_string<_Elem, _Traits, _Ax>::assign(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &, std::basic_string<_Elem, _Traits, _Ax>::size_type, std::basic_string<_Elem, _Traits, _Ax>::size_type) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 407
            instantiation of "std::basic_string<_Elem, _Traits, _Ax>::basic_string(const std::basic_string<_Elem, _Traits, _Ax>::_Myt &) [with _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>]" at line 18 of "/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.3/include/stdexcept"
"../ZLBus/../Commons/client.hpp", line 26: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
          detected during instantiation of "Client<T>::Client() [with T=uint16_t]" at line 32 of "../ZLBus/zlbus.cpp"
"../ZLBus/../Commons/client.hpp", line 27: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive
          detected during instantiation of "Client<T>::~Client() [with T=uint16_t]" at line 92 of "../ZLBus/zlbus.hpp"
Finished building: ../ZLBus/zlbus.cpp

Thank you,

Pibe

I compared the build options used for the release and debug builds, and these are the significant differences:

Varying any of these might avoid the problem.  Consider using Optimizer Assistant as an easy way to experiment with the options --opt_level and --opt_for_speed.  

I still would like a test case which allows us to reproduce the problem.  Are you willing to send us the code privately?

Thanks and regards,

-George

Hi George,

As I mentioned it earlier, setting optimization to the same values used by Debug does not modify the situation.

I have compiled Debug with 4.3.4 (instead of 4.3.3) and it is still working fine.

Finally, I cannot spend time creating testing cases for TI.  I can only pay for the tool (I have two licenses).  The error message clearly says this is an internal problem, please see that it is addressed promptly, as this tool is crucial for my work.

Regards,

Pibe

I understand your concerns with regard to protecting your code and being mindful of your time.  Nonetheless, the only way this issue can advance is with a test case which allows us to reproduce the behavior.  You already created the preprocessed file we need.  Are you willing to send it to us via private channels?

Thanks and regards,

-George

George,

My current contractual situation does not allow for that.  For me, as a consultant, dealing with the process of putting in place an NDA with TI will mean a delay measurable in months, without any certainty of success.

At least, I would like to see your suggestions for possible causes of the problem.  I mean, this is a very specific component that is failing under reasonably defined circumstances.

Regards,

Pibe

I have no legal expertise at all.  I can tell you this.  Over the years, we have received many source files from customers just like you.  I'm sure that, while some of them had NDA's in place, many did not.  Not once have I heard of a legal problem arising from such a test case.  And once is all it would take for us to never see a test case again.

Pibe said:

I would like to see your suggestions for possible causes of the problem.

That's impossible.  I realize that defies your common sense, so I'll try to explain.  

The compiler is composed of multiple phases.  The phase failing now is called the parser.  The source code for this parser is about 99% target independent.  And it is used in many parsers, not just for TI.  In various forms, this parser has been working in the wild for over 20 years.  It has processed every professional compiler test suite available many times over.  

From experience I can tell you that the root cause of this problem is due to some weird combination of circumstances in the source and build options that are unusual and impossible to predict.  

And that's why we cannot make any progress on this problem without a test case.

Thanks and regards,

-George

Don't you have a -dbg version for that executable that I can use and send you back more useful information?

If not, we can discuss alternatives on a private channel.

Regards,

Pibe

What about using a code obfuscator? It may make our debugging job 5x harder, but it can also make any shared code useless to anyone else.

I do not know one that would work on Linux.

If you've got one any other operating system, you should be able to generate a preprocessed file with the TI tools and obfuscate that on the other operating system.

Checking MISRA "Documentation" is equivalent to passing --check_misra=3 to the compiler.  Looking at MISRA-C 2004, rule 3 has several sub-rules, mostly dealing with documenting any dependence on implementation-defined behavior and the like.  I'm not sure how the compiler is supposed to check that, but that's not the concern here.

The good news is that I've been able to construct a test case which crashes in _Tidy when using --check_misra=3 and no other options.  I'll check it out.

Great!  Please let me know when you reach the end of it.

Regards,

Pibe

The problem is that the MISRA checker finds what it thinks is a function call in std::string::_Tidy that uses a template parameter as the name of the function to call, which is clearly not correct, but there's no obvious fix.  The initial consensus is that you're not supposed to use MISRA C to check C++ code, and that we should consider making it a fatal error to try to use --check_misra with C++ code.  I've attached my test case to SDSCM00050814 for further analysis.  This bug will go in the queue and will be addressed in turn.

Agree.  I am not sure how that option ended up being checked (a C project used as a template?).

Regards,

Pibe