Create 4+ threads on ESP32 lead to crash


What am I doing

I have a socket server running on ‘DOIT Esp32 DevKit v1’ board, which receive external command and execute. Some of the command need to start a new thread to handle the task.


The board keeps crash if the total thread number is more than 4. From time to time, I am lucky to create 6 threads, then the board crashed.

Need Help

  1. According to the online Zerynth Docs, new thread shouldn’t result in crash, there should be a RuntimeError instead of crash. Did I do something wrong here?
  2. Can I use the Register dump info and some debug tools to identify the cause by myself? Even a tiny hint should be useful for how to avoid the problem.


here’s the code fragment:

def start():        
    print('reader thread started')    
    while True:    
            result = read()   # read GPIO status, UART devices etc....and the board keeps crash even if this line is commented , so there is no relationship between read() and crash
        except Exception as e:
            print("read error",e)

def handle_request():   #call 4~6 times, the board will crash

and the stack:

Guru Meditation Error: Core 0 panic’ed (LoadProhibited)
. Exception was unhandled.
Register dump:
PC : 0x40114a2c PS : 0x00060d30 A0 : 0x80114ad4 A1 : 0x3ffcf100
A2 : 0x3ffd8bfc A3 : 0x00000001 A4 : 0x00001178 A5 : 0x00000010
A6 : 0x3ffce0e8 A7 : 0x3ffd9260 A8 : 0x3ffd664c A9 : 0x3ffcf0f0
A10 : 0x00007ffb A11 : 0x00000000 A12 : 0x00001178 A13 : 0x3ffd9d74
A14 : 0x000069c8 A15 : 0x00000117 SAR : 0x00000018 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000012 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0x00000000
Backtrace: 0x40114a2c:0x3ffcf100 0x40114ad1:0x3ffcf130 0x4010a7cd:0x3ffcf150 0x40115c98:0x3ffcf1a0 0x4010d625:0x3ffcf1c0 0x4010c7d7:0x3ffcf210
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
mode:DIO, clock div:2
ho 12 tail 0 room 4
entry 0x40078d64


Hi @Zhang_Lance,

handling each request on a separate thread might not be the most efficient solution on a constrained device: the board crashes due to insufficient memory available to be allocated for a new thread (you correctly pointed out that a RuntimeError should be a cleaner way to handle such a scenario, we will fix this in a future release).

What I can suggest you, for example, is to put received commands in a queue and process that queue on a single separate thread. You might also increase the number of threads and queues to make the application more responsive.
Anyway I think you should keep the number of threads fixed/limited.

Let me know if the proposed one can be a good solution for your setup :slight_smile:


thanks for your suggestion, I’ll do it in your way, it’s the right way for a mcu :slight_smile: