Kernel Panic when using SSL connections (MQTT or HTTPS)

[aktivalux]

Hello,

I am using the LoPy and PySense board. For testing I use WiFi connectivity. When connected via WiFi I want to send the data via MQTT or HTTP. In both cases I want to use SSL. However when I try to do so my LoPy crashes due to some kernel panic and I have no idea why. If using non-SSL it works for both, MQTT and HTTP connections.

Am I missing something? Do I have to provide the trusted CAs somewhere? The error message is not really helpful

My main.py
https://pastebin.com/JjksiJeZ

The error output:
https://pastebin.com/CdF48CGD

For HTTP requests I used this library: https://github.com/micropython/micropython-lib/blob/master/urequests/urequests.py
For MQTT I used https://github.com/micropython/micropython-lib/blob/master/umqtt.simple/umqtt/simple.py

[this.wiederkehr]

@aktivalux said in Kernel Panic when using SSL connections (MQTT or HTTPS):

-35123

You mean it raises OSError: -35123? Actually -35123 beeing -0x8933 is out of the error range defined by mbedtls. Is there a typo in this numer?

https://tls.mbed.org/api/error_8h.html

[aktivalux]

I also have something above 50kB of free mem in mind (this refers to the free heap)

Ok then I had just expected to have some more memory/heap for my variables and objects. Because when using e.g. MQTT it drops down to around 20KB of free mem - which is not too much tbh.

Do you mean successfull results?

The result of the HTTPs request (print(response.text)) gave me numbers like -35123 when making a request to https://httpbin.org/get but (at least I no longer got a kernel panic :) ). I haven't had time yet to check why and if for example something was wrong with the ca_cert used. When making a HTTP request I get the expected JSON response.

[this.wiederkehr]

There are two kind of memory usages referred to as the stack and the heap. Each os task has his own stack whereas the heap is shared betwee all the tasks. Search for it on google to get more elaborate explanation. You can not in general decrease the stack usage by optimizing memory usage. Stack usage has more to do with function call depth (how deep your function calls are nested), that is why it is so hard to determine a reasonable size for it (and is usualy done empirically).

gives "other" results

Do you mean successfull results?

I also have something above 50kB of free mem in mind (this refers to the free heap).

[aktivalux]

Thanks for replying. Indeed it looks like playing around with the stack_size gives "other" results. So basically I can interpret the error message as some kind of out of memory error, correct?

I tried troubleshooting / improving mem consumption of my script but actually couldn't find anything (with my very limited python skills) which could cause high memory usage. Also I was wondering how this little code can exhaust the 512KB of RAM. So I added some print(gc.free_mem()) statements. Even tho I commented out my whole code it only returned 59200B of free mem. Is this expected?!

[this.wiederkehr]

Debug exception reason: Stack canary watchpoint triggered (MPThread)

There are canary bits at the end of the stack which I think get checked on the context switch of the os. These canary bits got overwritten most likely by the MPThread task or just another out of bounds memory access. This is the reason for the panic.

As you are doing tls in the thread I can well imagine that the default allocated 4096bytes stack per thread are not enough.

You can try to increase the stack allocated for the MPThread task:
By calling
_thread.stack_size([size])
prior to createing the thread.

See the documentatio for additional information:
https://docs.pycom.io/chapter/firmwareapi/micropython/_thread.html