Accessing filesystem from threaded webserver crashes the machine

[amotl]

Dear Jean-Christophe,

thanks for conceiving and maintaining this fine project.

Similar to #54, we are either getting "maximum recursion depth exceeded" exceptions or blatant "stack overflow" crashes when accessing the filesystem from a route/handler within a threaded webserver. We are using the Pycom FiPy on a recent Pycom firmware version.

Maybe you have any idea about this? Otherwise, let's keep this as a reference for other visitors.

With kind regards,
Andreas.

---

***ERROR*** A stack overflow in task MPThread has been detected.
abort() was called at PC 0x40099324 on core 1

Backtrace: 0x400991b3:0x3fff0870 0x4009930b:0x3fff0890 0x40099324:0x3fff08b0 0x40095a5d:0x3fff08d0 0x400976a4:0x3fff0900 0x4009765a:0x3ffdd458
[...]

================= CORE DUMP START =================
dE4AABMAAABsAQAA
[...]
================= CORE DUMP END =================
E (6171) esp_core_dump: Skipped 1 tasks with bad TCB!
E (6175) esp_core_dump: Crashed task has been skipped!

[jczic]

Hello @amotl and thank you for your message.
Yes, it's a problem that occurs when there are too many functions called in recursion.
In this code, and in particular when using "template" (pyhtml), it can indeed happen :(
This max of recursion can be increased in the Firmware src (C code) but I'm thinking about writing a new micro-web-serveur using my lib : https://github.com/jczic/XAsyncSockets (all from I/O).

[amotl]

Dear Jean-Christophe,

thanks for taking the time to answer on our observations.

Yes, it's a problem that occurs when there are too many functions called in recursion.

Thanks for acknowledging that in this context. It tremendously helps us to see better through the fog sometimes covering the nitty gritty bottom-/system-half within MicroPython development and also helps us not to chase any ghosts ;].

In this code, and in particular when using "template" (pyhtml), it can indeed happen :(

It looks like the firmware we are currently conceiving at [1] works reasonably without any crashes right now but we would be happy to learn about the compile time constant/variable we would have to amend for MicroPython if we are running into the problem again.

I'm thinking about writing a new micro-web-serveur using my lib: https://github.com/jczic/XAsyncSockets (all from I/O).

We already spotted this guy and look very much forward to it. If time permits, we will be happy to test this library as a replacement for the current MicroWebSrv and wish you good luck for the next development iterations.

With kind regards,
Andreas.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware

[jczic]

Re and thank you for your response. Just, can you try to compile MicroPython firmware with the following change : In "mpconfigport.h" -> set MICROPY_STACK_CHECK to zero. Normally, that's disable recursion depth checking. Tell me if that works for you. Good luck and have a nice day. Le mer. 11 sept. 2019 à 18:53, Andreas Motl <[email protected]> a écrit :

…

Dear Jean-Christophe, thanks for taking the time to answer on our observations. Yes, it's a problem that occurs when there are too many functions called in recursion. Thanks for acknowledging that in this context. It tremendously helps us to see better through the fog sometimes covering the nitty gritty bottom-/system-half within MicroPython development and also helps us chasing any ghosts ;]. It looks like the firmware we are currently conceiving at [1] works reasonably without any crashes right now but we would be happy to learn about the compile time constant/variable we would have to amend for MicroPython if we are running into the problem again. I'm thinking about writing a new micro-web-serveur using my lib: https://github.com/jczic/XAsyncSockets (all from I/O). We already spotted this guy and look very much forward to it. If time permits, we will be happy to test this library as a replacement for the current MicroWebSrv and wish you good luck for the next development iterations. With kind regards, Andreas. [1] https://github.com/hiveeyes/hiveeyes-micropython-firmware — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58?email_source=notifications&email_token=AAD2ALDVUTQEXETLKHDYVQ3QJEPBRA5CNFSM4IFT2A6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6PE5YI#issuecomment-530468577>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD2ALA64U45ZVUIJJTYXYTQJEPBRANCNFSM4IFT2A6A> .

-- *Sincèrement,*

[amotl]

Dear Jean-Christophe,

we just recognized the release of MicroWebSrv2. We wanted to mention that we just referenced it at [1] and look very much forward getting our hands dirty with it. Until then, we want to salute you for the new release.

From giving the repository and documentation a short visit, this looks like a huge leap forward. Thanks a bunch for your continuous work on this guy!

Cheers,
Andreas.

[1] https://community.hiveeyes.org/t/http-und-webbasierte-konfiguration-des-terkin-datenloggers-zur-implementierung-eines-captive-portal/2270/25

[jczic]

Dear Andreas, thank you for your feedback, it gives me great pleasure :) Yes, microWebSrv2 is really better than its predecessor. In addition, if you have again problem with recursive depth, you can adjust the stack size. This web server works on CPython too and can processes to thousand of connections (on a tuned linux for example)! Feel free to let me know how you are progressing with all this. Have a nice day! Le dim. 20 oct. 2019 à 17:37, Andreas Motl <[email protected]> a écrit :

…

Dear Jean-Christophe, we just recognized the release of MicroWebSrv2 <https://github.com/jczic/MicroWebSrv2>. We wanted to mention that we just referenced it at [1] and look very much forward getting our hands dirty with it. Until then, we want to salute you for the new release. From giving the repository and documentation a short visit, this looks like a huge leap forward. Thanks a bunch for your continuous work on this guy! Cheers, Andreas. [1] https://community.hiveeyes.org/t/http-und-webbasierte-konfiguration-des-terkin-datenloggers-zur-implementierung-eines-captive-portal/2270/25 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58?email_source=notifications&email_token=AAD2ALCQFZDMLE2NCDRHE4LQPR3JXA5CNFSM4IFT2A6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYM2BQ#issuecomment-544263430>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD2ALEHBGOOZSLE4U3DO4TQPR3JXANCNFSM4IFT2A6A> .

-- *Sincèrement,*