• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 83 subscribers
  • Views 1190 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Concerto: stdlib-function "bsearch" crashes after upgrade of the ARM Compiler Tools

Christian L
Intellectual 630 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi all,

I recently installed CCS 5.4.0.00091 after uninstalling my previous version 5.3.x. I then ran into some very strange behaviour when importing an existing project that has been running ok for over a year, using compiler version 4.9.1. I got the usual warning in CCS 5.4 that this compiler version was not currently installed, and that the effective compiler version therefore was version 5.0.6. I used Help/Install New Software to install version 4.9.2 and that appears to have fixed my problem.

However, I need to find out what the root-cause was and eventually upgrade my ARM Compiler Tools.

The root-cause appears to be a bug within the runtime-support implemention of the binary search algorithm, that is, the function "bsearch" as declared within header-file "stdlib.h". I believe the problem should be reproducible for anyone who have these or similar versions installed.

1. Grab the blinky project (C:\TI\controlSUITE\device_support\f28m35x\v150\F28M35x_examples_Master\blinky).

2. Add some heap-size (e.g., 1024)  (Only for printf to highlight the problem).

3. Set compiler version to 4.9.2. or earlier.

4. Modify blinky.c to include stdlib.h and make a call to bsearch(). For example, modify the while(1) loop to read as follows:


Also, add a comparison function above the main():

5. Run the project. With the above, you should see the following printed to CCS console:

Turn on LED.

Perform binary search.

Found 32 at array position 3.

Turn off LED.

Turn on LED.

Perform binary search. .... And so on.

6. Now, for the interesting bit, please change the compiler version to 5.0.4, 5.0.6 or 5.1.1, and run it again. This time it will crash with a hard fault when calling bsearch() the first time.The crash seems to be be due to stack overflow that is, by stepping through the code, I can see that the bsearch algorithm seems to be goining into an infinite recursion, laying itself on the stack endlessly until a hard fault is provoked.

Am I being fooled by something else here? For example, mismatch between rts headers and lib. I don't get this, is the really a bug in the rts?

PS: I also attached my example project as a zip-file.

Best regards,

Christian

blinky.zip
  • 0
    Guru 192875 points

    Hi Christian,

    What you're experiencing is the compiler instability. I experienced the same and so had to revert back to previous compiler version. I read in some thread that TI is working on stability of CCS 5.4 and its repositories.

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Intellectual 630 points

    Thanks Gautam,

    Which compiler version did you end up reverting to? In other words, what is the last trustworthy version of the ARM compiler tools? I ended up using 4.9.2.

    This is quite a serious problem so it would be appropriate if someone from TI please could comment?

    The only excuse for one compiler to give a different behaviour than another is off course if the source code includes some undefined behaviour. However I cannot see anything undefined in the modified blinky example attached in my previous post.

    Best regards,

    Christian

     

  • 0 in reply to Christian L
    Intellectual 630 points

    Could someone from TI please comment on this problem (and perhaps run the example I attached to see if it is reproducible)?

    Best regards,

    Christian

  • 0 in reply to Christian L
    TI__Guru* 91930 points

    Christian,

    We are working on reproducing the problem.  Will get back to you soon.

    -Lori

  • 0 in reply to Lori Heustess
    TI__Guru* 91930 points

    Christian,

    I took the project you provided and loaded the RAM build .out as you supplied.  From the .map file it appears this was built with compiler 5.1.1.

    My observation was a bit different than yours.  I never made it to the bsearch() function.  The code never got past the first printf() message - it seems to print it out and then goes into the weeds.   This doesn't seem to match your description since I don't get as far as the bsearch() function.

    So I increased the heap size since printf was behaving poorly (0x2000) and rebuilt with ARM codegen 5.1.1.  This time the messages appear to be correct and the LED is blinking at the rate expected.

    I've attached the project.  Your original .out file has been renamed "blinky_m3_511_original.out".   Can you try the .out I provided and see if bsearch works correctly on your end?1018.blinky_larger_heap.zip

    Regards,

    Lori

  • 0 in reply to Lori Heustess
    Intellectual 630 points

    Thank you Lori,

    You are correct that the project I had previously attached did not reproduce the behaviour I was describing, and in addition it had a heap-size problem (with the new compiler).

    It turns out that the problem I was having has to do with C versus C++ linkage and calling the bsearch() from a .cpp file, using the new ARM compiler. Please find attached a project illustrating the problem with compiler version 5.1.1. Also, I paste in a screen-shot of a debug session with this project, where I have "stepped into" (F5) the bsearch() function a quite a few steps. As can be seen, the crash is due to an infinite recursion.

     

    From C++, I am including <cstdlib> and calling the function std::bsearch(). This has worked fine for previous compilers but does not work with 5.0.4, 5.0.6 or 5.1.1. Should it not always work, or do I violate any C/C++ interfacing rules? In any case I think I will call this function only from .c files from now on. For those how do not want to open the whole project I paste below the main part of the problematic code:

     

    Best regards,

    Christian

    blinkyBSearchCpp.zip
  • 0 in reply to Christian L
    TI__Guru* 91930 points

    Christian,

    Thank you.  I've reproduced the issue and I have asked the compiler team to take a look.

    Regards,

    -Lori

  • 0 in reply to Lori Heustess
    Guru 20525 points

    Hello Lori!

    Could you please comment this thread?http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/286305.aspx

    Thanks,

    Regards,

    Igor

  • 0 in reply to Christian L
    TI__Guru* 91930 points

    Christian,

    Yes, unfortunately you have hit upon a known bug.  They indicated there is one possible workaround until the next codegen version is released:

    One workaround is to build with the strict mode option --strict_ansi instead of --gcc.

    If you have other questions regarding this bug I can move the thread to the codegen forum for the experts there.

    Thank you

    Lori

  • 0 in reply to Lori Heustess
    Intellectual 630 points

    Thanks Lori,

    That explains it.

    No need to move this thread to the other form, but could you please post a link to the bug report (or something else) that explains it.

    (I need gcc-extensions for something else so my workaround will be to either stick with version 4.9.2 or refactor to call bsearch() only from pure C functions.)

    Best regards,

    Christian

  • 0 in reply to Christian L
    TI__Guru* 91930 points

    Christian L said:

    No need to move this thread to the other form, but could you please post a link to the bug report (or something else) that explains it.

    (I need gcc-extensions for something else so my workaround will be to either stick with version 4.9.2 or refactor to call bsearch()

    Christian,

    https://cqweb.ext.ti.com/cqweb/#/SDO-Web/SDOWP&format=HTML&loginId=readonly&password=&version=cqwj

    Search for: SDSCM00047883

    The bug is against the MSP430 tools but applies to ARM as well.

    Thank you

    Lori

  • 0 in reply to Lori Heustess
    Intellectual 630 points

    Do you know if this bug has now been fixed in newer (than 4.9.x) ARM compiler version?

    Christian