Create 4+ threads on ESP32 lead to crash


#1

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.

Problem

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.

Thanks!

here’s the code fragment:

def start():        
    print('reader thread started')    
    while True:    
        try:    
            print('reading...')
            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
            print(result)
            sleep(6000)
        except Exception as e:
            print("read error",e)


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

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
Rebooting…
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:3064
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:11504
entry 0x40078d64


#2

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:


#3

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