search

cesanta / mongoose-os

Mongoose OS - an IoT Firmware Development Framework. Supported microcontrollers: ESP32, ESP8266, CC3220, CC3200, STM32F4, STM32L4, STM32F7. Amazon AWS IoT, Microsoft Azure, Google IoT Core integrated. Code in C or JavaScript.
https://mongoose-os.com
Other
2.51k stars 429 forks source link

Stack canary watchpoint triggered (wifi) #550

Closed VaclavVejrosta closed 4 years ago

VaclavVejrosta commented 4 years ago

Hi, I have got this problem when ESP32 tries to connect to wifi. However it never happens with mos version 2.17 but only when I update mos to version 2.18. Please see attached logs:

image

image

nliviu commented 4 years ago

Try to disable multicore:

build_vars:
  ESP_IDF_SDKCONFIG_OPTS: >
    ${build_vars.ESP_IDF_SDKCONFIG_OPTS} 
      CONFIG_FREERTOS_UNICORE=y
VaclavVejrosta commented 4 years ago

Great. It seems it helped. And this solution helped also to solve issue #551. Thank you

Btw. Does it mean that I can´t make my tasks running on both cores?

nliviu commented 4 years ago

As long as only 1 core is available, you can't.

rojer commented 4 years ago

basically, the reason is running out of stack space in debug handler. stack space is reserved for individual tasks, and the packet processor task has smaller stack than others. *printf family of functions use a lot of stack variables. in the trace we see that debug output happens inside a printf function which then trickles down all the way to mgos_debug, triggers an event which invokes some custom logging function that tries to print a json message, which invokes vprintf again. then the whole thing explodes. in general printing to websocket from packet processor is not a good idea, either... this is why remote logging is hard. this is also why in my recent patch i had to get rid of snprintf in udp logging, replacing it with simple itoa calls - https://github.com/cesanta/mongoose-os/commit/19ce346747c07367a3d422f6634186482a12a913

rojer commented 4 years ago

i'm not sure why this is different on single core vs multicore though, you'd think that connection logic would be the same... this is why multicore/multithreading is hard :)

Harvie commented 4 years ago

Stack size (per task) is configurable in FreeRTOS... Maybe we need to increase this constant?

rojer commented 4 years ago

yeah, can try that