C++ STL Vector container locks on allocation of new memory

I cannot reproduce this.  Please generate and post your linker map file (linker option --map_file).  Please post your exact command-line arguments and the version of the Launchpad you are using.

Please describe the conditions and symptoms exactly.  You said you observed "lockups" with this code; do you mean the code as it is posted, exactly, with the reserve call commented out?  What do you mean when you say you get a "hang" with the two commented-out lines?  Do you mean commenting them out precipitates the "hang", or un-commenting them?  Is there a difference in the behavior of the bug when these lines are commented out?  Does the program print anything at all?

Can you reproduce this on the simulator?

Linker File: Due to sheer size: http://pastebin.ca/2306751
Launchpad Revision: EX-LM4F120XL Rev A
Command line arguments:

'Invoking: ARM Linker'
"D:/ti/ccsv5/tools/compiler/tms470_4.9.5/bin/cl470" -mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me -O2 -g --gcc --define=ccs="ccs" 
--define=PART_LM4F120H5QR --define=TARGET_IS_BLIZZARD_RA1 --diag_warning=225 --display_error_number --gen_func_subsections=on 
--ual -z --stack_size=512 -m"testvectors.map" --heap_size=0 -i"D:/ti/ccsv5/tools/compiler/tms470_4.9.5/lib" -i"D:/ti/ccsv5/tools/compiler/tms470_4.9.5/include" 
--reread_libs --warn_sections --display_error_number --rom_model -o "onewire-test.out"  "./stellaris-pins/Pin.obj" "./stellaris-pins/DigitalIOPin.obj" 
"./utils/uartstdio.obj" "./startup_ccs.obj" "./onewire.obj" "./OneWireMaster.obj" 
-l"D:/StellarisWare/boards/ek-lm4f120xl/hello/ccs/../../../../driverlib/ccs-cm4f/Debug/driverlib-cm4f.lib" -l"libc.a" "../hello_ccs.cmd"

Compiler flags set:

-mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me -O2 -g --include_path="D:/ti/ccsv5/tools/compiler/tms470_4.9.5/include" 
--include_path="D:/StellarisWare" --gcc --define=ccs="ccs" --define=PART_LM4F120H5QR --define=TARGET_IS_BLIZZARD_RA1 --diag_warning=225 
--display_error_number --gen_func_subsections=on --ual

Linker flags set:

-mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me -O2 -g --gcc --define=ccs="ccs" --define=PART_LM4F120H5QR 
--define=TARGET_IS_BLIZZARD_RA1 --diag_warning=225 --display_error_number --gen_func_subsections=on --ual -z 
--stack_size=512 -m"testvectors.map" --heap_size=0 -i"D:/ti/ccsv5/tools/compiler/tms470_4.9.5/lib" -i"D:/ti/ccsv5/tools/compiler/tms470_4.9.5/include" 
--reread_libs --warn_sections --display_error_number --rom_model

Specific steps to reproduce:

1. Enter the on-device debugger
2. Step through to the first line of "testVector.push_back(5);
3. Step into this line
4. Step through until you reach the Vector line 704 "insert(end(), _Val);"
5. Attempting to step past this line will result in a hang. Instead, step into the function
6. Step past until you reach the else if clause at line 1024
7. Slowly step through this function, this is the allocation of additional memory.
8. The final step I can locate is within the file "xmemory", where "
       return ((_Ty _FARQ *)::operator new(_Count * sizeof (_Ty)));" is found, and at this point "hangs".

The debugging interface indicates it is continuing to process and waiting for the next break point. I cannot restart the device from here, I must first pause execution and then restart. I do not lose control of the device, I can still pause execution and resume execution. Without the debugger the LM4F will proceed through the UART print statements until "Add  elements to vector", and it will not proceed further.

The same effect can be seen on the second commented out line, which also attempts to reserve memory for the vector. It will "hang" in the same location with the same overall effect.

I have not tried the simulator to date. I am looking at various threads in an attempt to get the simulator working but for now I will supply this post so that you may be able to proceed.

Yep, that would be it. Dug through the Properties panel in CCS and came across the Heap Size option under 'Basic Options' in the ARM Linker. Looks like the new default for the latest CCS version is "0", which would explain the very low value. I've bumped it up to 24576 like you suggested and it is now properly assigning items to the array.

Prior to the update, it would simply pass through the reserve or push_back functions without actually modifying the vector. Program flow would not become 'hung' inside the Vector functions. Is there a specific reason for this change, or was it all undetermined behavior to begin with?

It defaults to zero?  That's weird...

I'm sorry, I'm not familiar with the implementation of the STL.  I can tell you that 8 bytes is too small for the preferred method of signaling STL memory allocation errors, which is through a C++ exception (which are not enabled by default).  I expect that with or without exceptions enabled, an effectively zero-sized stack is pretty much guaranteed to make STL uses fail.

Absolutely, I didn't think to take a look at the heap size. This is my first time actually using the STL on an embedded project, clearly I've got a bit more learning to do. Thanks for the help!