The SDK 3.0.0 allocator fails catastrophically after out-of-memory condition

[TerryE]

If an os_malloc_dram() returns a NULL pointer and the application then recovers by freeing memory (a common usecase for apps which use a lazy garbage collection scheme), then the system should recover and continue processing as normal.

Actual behaviour

• On SDK 2.2.1 (6ab97e9). this all works as expected and the test harness below can be called repeatedly with the allocator recovering after each out-of-memory event.
• On SDK 3.0.0 (d49923c), the allocator notes a vPortFree 517 line assert fail on attempting to free the last block allocated. The next alloc call goes into an infinite loop and finally triggers a a soft WDT reboot.

Test code

void malloc_test () {
  unsigned i, t0 = system_get_time();
  size_t **b, *p = (void *) ~0;
  static const size_t allock_chunk = 1024;
  system_set_os_print(1);
  os_printf( "SDK %s\n", SDK_VERSION );
  for (i = 0; p; i++) {
    p = os_malloc( allock_chunk );
    if (i == 0)
      b = (size_t **) p;
    b[i] = p;
    os_printf ("%3u %p %6u %u\n", i, p, 
               system_get_free_heap_size(), system_get_time() - t0);
  }
  for (i -= 2; i != ~0; i--) {
    os_printf ("Freeing %3u %p\n", i, b[i]);
    os_free(b[i]);
  }
}

Test Results

NodeMCU 2.2.0.0 build unspecified powered by Lua 5.1.4 on SDK 3.0.0(d49923c)
> node.test()
SDK 3.0.0(d49923c)
  0 0x3fff2460  57048 174
  1 0x3fff2870  56008 389
  2 0x3fff2c80  54968 600
... (lines 3..51 precised)
 52 0x3ffff7a0   2968 121161
 53 0x3ffffbb0   1928 123764
E:M 1040
 54 0x00000000   1928 127211
Freeing  53 0x3ffffbb0
vPortFree 517 line assert fail
Freeing  52 0x3ffff7a0
... (lines 51..2 precised)
Freeing   1 0x3fff2870
Freeing   0 0x3fff2460
>  (Note that the application is not responding at this point and hangs until WDT fires.
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 32532, room 16 

Hardware

Wemos D1 Mini Pro running ESP8266 at 80MHz

[TerryE]

I note that the last version of the 3.0,0 branch SDK 3.0.1-dev(fce080e) does not exhibit this error, but it also has less ram available than 2.2.1 👎

[TerryE]

A codicil to my last comment SDK 3.0.1-dev(fce080e) does not exhibit this error if compiled with -DMEM_DEFAULT_USE_DRAM, with it the test gives:

SDK 3.0.0(d49923c)
  0 0x3fff2458  57104 176
  1 0x3fff2868  56064 393
...
 52 0x3ffff798   3024 121163
 53 0x3ffffba8   1984 123766
E:M 1040
 54 0x00000000   1984 127211
Freeing  53 0x3ffffba8
vPortFree 517 line assert fail
Freeing  52 0x3ffff798
...
Freeing   1 0x3fff2868
Freeing   0 0x3fff2458
> 
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset

or basically the same error.