Syscall _exit() on string manipulation

[CPaye.1]

I am using TGX v4.16.1 and CubeIDE v1.8.0. My hardware platform is the STM32429 Eval board.

The code for the hardware backend was autogenerated from either TGX Designer or CubeMx (I do not recall which one at this point).

My issue is that the application is crashing (jumping to the syscalls _exit function) when I use C++ strings in the IDE build but not the build generated by the TGX environment using the gcc makefile.  

In my application I am using C++ string variables in a presenter to create formatted content to use when updating the view.  What I observe under the IDE debugger is that the strings have an initial allocation of 16 bytes. If I exceed this when I build a string or if I try to manipulate the allocated size, the application crashes. This does not happen with the build generated in the TGX environment - the dynamic allocation occurs as expected.  

Below is a screenshot of a code sample and the variable values. This is a simplified version of what the code does. The reserve operation is not a part of my normal application - it is just there for testing.

I am not seeing the RTOS task stack overflow hook being called. I also tried using the TGX linker file with the IDE build and the crash still occurs.  

I do not have to use C++ strings, I just found they were convenient for the operations I want to do. If I cannot figure this out I will just convert to c-strings but I would like to understand the issue.

Any thoughts?

 

[TDK]

If new() is calling abort(), I expect a heap allocation is failing. This isn't a stack problem.

std::string uses the heap, so you need to ensure enough room exists. Possibly this is controlled on a per-task basis, not sure.

[CPaye.1]

Thanks for the feedback. I forgot to include that I have investigated the heap. I bumped up the heap in the IDE linker file and that did not work. As a gut check I also tried the TGX linker file with the IDE in case there was something in there that I was missing. Same issue.

Both builds use the same FreeRtos config file which provides the RTOS heap allocation.

[CPaye.1]

I have a workaround but not really an understanding as to why it works.....

The issue turns out to be the implementation of the _sbrk function. The call to _sbrk function to malloc more space for the string was triggering the ENOMEM error. Surprisingly if I comment out the function, the application compiles and uses the sbrk function native to the compiler.