I've now also results from testing different heap placements in the SPIRAM address space.

I've done these tests on branch "master" with duktape running on core 1 (= no heap corruption crashes).

To shift the duktape heap location into the upper SPIRAM regions, I added this modification to DukTapeInit():

    void *shiftmem = ExternalRamMalloc(2*1024*1024);
    umm_memory = ExternalRamMalloc(memsize);
    ESP_LOGI(TAG, "Duktape: shiftmem=%p umm_memory=%p", shiftmem, umm_memory);
    if (shiftmem) free(shiftmem);

I've tried shifting into the upper 2 MB as shown here, and then shifting by just 1 MB up to place the head at the upper end of the lower 2 MB (so memory corruption by other processes is unlikely). I've then run the event test script 15 times until aborted by the error and collected the total loop counts.

Result: there is a strong correlation between the heap memory half used and the error frequency: with the heap in the upper half (shifted by 2 MB), the loop will run >10x longer on average than with the heap in the lower half.

In absolute numbers: the average loop count with the heap in the lower 2 MB SPIRAM was ~ 3,000, with the heap shifted into the upper 2 MB it was ~ 40,000.

Within the lower half, there is no difference between shifting by 1 MB and no shifting, so it's most probably not caused by some other process corrupting the duktape heap region.

My conclusion would be now, this is still the SPIRAM bug, or a previously undetected variant thereof. Can some others please try to reproduce my results?

Regards,
Michael

Am 17.09.21 um 10:56 schrieb Michael Balzer:

I just remembered…

https://github.com/espressif/esp-idf/issues/2892#issuecomment-459120605

…and as Duktape runs on core #1, I now test shifting the Duktape heap into the upper 2 MB of SPIRAM.

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26