While Edgar was writing some test code, so was I. :)

#include <memdebug.h>

String foo;

String f() {
  String s = String("");
  s += "a"; // ...
  s += "bc"; // ...
  return s;
}  // end of f

void showMemoryUsage ()
{
  Serial.println (F("---------------"));
  Serial.print (F("Largest block in freelist: "));
  Serial.println (getLargestBlockInFreeList ());
  Serial.print (F("Largest available memory: "));
  Serial.println (getLargestAvailableMemoryBlock ());
  Serial.print (F("Free memory: "));
  Serial.println (getFreeMemory ());
  Serial.print (F("address of foo data = "));
  Serial.println ((int) foo.c_str ());
} // end of showMemoryUsage

void setup() 
{
  Serial.begin (115200);
  Serial.println ();
  showMemoryUsage ();
  Serial.println (F("Calling f() ..."));
  foo = f ();
  showMemoryUsage ();
  Serial.println (F("Calling f() ..."));
  foo = f ();
  showMemoryUsage ();
  Serial.print (F("foo = "));
  Serial.println (foo);
}  // end of setup

void loop ()
{
}  // end of loop

Memory debug library from http://andybrown.me.uk/wk/2011/01/01/debugging-avr-dynamic-memory-allocation/

Output:

---------------
Largest block in freelist: 0
Largest available memory: 1675
Free memory: 1677
address of foo data = 478
Calling f() ...
---------------
Largest block in freelist: 2
Largest available memory: 1669
Free memory: 1675
address of foo data = 482
Calling f() ...
---------------
Largest block in freelist: 2
Largest available memory: 1669
Free memory: 1675
address of foo data = 482
foo = abc

The address of the data in foo has changed from 478 to 482, so my prediction above was right. The function f() made a String, but a second copy was returned, hence we have now "lost" 4 bytes in the heap. Well, not lost, but there is a gap.

Calling f() a second time did not make the fragmentation worse.

BTW, this is unnecessary:

  String s = String("");

Just write:

  String s;

You are invoking a second String just to provide something to copy into the first String. Strings start off empty so this is just wasted time.

The worst line in your example is this:

s += "a"; // ...

Any sort of loop that adds one byte to a String is potentially going to fragment memory. First the String class allocates zero bytes for the string, then when you add a byte, it has to allocate one byte, then when you add another byte it has to deallocate (free) that byte and allocate two bytes, and so on.

The allocator tries to be efficient, so eventually when you get up to three bytes you will, with luck, actually get the memory previously allocated to the one-byte string followed by the two-byte string.

But if other allocations have occurred (eg. another use of String elsewhere in the program) this might not be possible. Eventually you have lots of small gaps of maybe one or two bytes, with other stuff inbetween. Unless they are adjacent they cannot be recombined into a bigger block. This is your "fragmentation".

The worst line in your example is this:

s += "a"; // ...

Any sort of loop that adds one byte to a String is potentially going to fragment memory. First the String class allocates zero bytes for the string, then when you add a byte, it has to allocate one byte, then when you add another byte it has to deallocate (free) that byte and allocate two bytes, and so on.

The allocator tries to be efficient, so eventually when you get up to three bytes you will, with luck, actually get the memory previously allocated to the one-byte string followed by the two-byte string.

But if other allocations have occurred (eg. another use of String elsewhere in the program) this might not be possible. Eventually you have lots of small gaps of maybe one or two bytes, with other stuff inbetween. Unless they are adjacent they cannot be recombined into a bigger block. This is your "fragmentation".

When you += "a", it does not free the previously allocated space: it calls realloc() to grow the buffer, and realloc() tries to grow it in place. This works fine, without fragmentation, as long as your buffer is at the top of the heap.

Good point, however if you have multiple String instances, this may not work.

Edgar Bonet is right, however there is certainly the potential, with multiple String instances, for each of them to prevent the others from growing their buffer size neatly. In the example in the question, you will probably find that when f() returns, it returns a copy of the String allocated on the stack, thus we now have 2 x String instances.