https://toitlang.org/ logo
Join Discord
Powered by
Exception Error: Malloc Failed
# help
k
Hello, so I've encountered this problem, that I get a "Malloc Failed" exception thrown, then I try to make an HTTP-request. The request failing is actually not the problem though, the request itself will be made, during the boot-up of the device in my program. Although this should not be necessary for the rest of my program to run. But the malloc failing, then stops the device from running its loop, and then gets stuck trying to connect to the configured wifi, but the loop of the program never starts again, unless I do a manual reboot of the device. Is there any way to avoid this, and keep the loop going? I've posted the stack-trace and the part of the code from which the exception is thrown.

https://cdn.discordapp.com/attachments/1131889584142299166/1131889584549154866/image.png▾

https://cdn.discordapp.com/attachments/1131889584142299166/1131889585023094904/image.png▾

f
Which system are you using? Pure Toit, Jaguar, Artemis, Toit v1? Could you provide a trace of what is happening (the malloc failed, followed by the attempts to connect, ...)
k
I think it's Toit v1, we're using console.toit.io as management. Thing is, it actually connects to the wifi, but the loop for the installed app never starts again. Instead, the device just disconnects and then it connects again, disconnect, then connects etc etc. The trace of the exception should be in the second picture I posted
It fails at the tls-handshake
f
I missed the second picture... Yes. That's clearly v1.
TLS connections are extremely memory hungry. We have since done a lot of improvements on that, but these are all in v2, not v1. I would recommend to start migrating to v2 and Artemis. In the short term: - Set the max-offline to something else than 0s (if you haven't done so yet). Maybe 10m? - Try to run the program with an interval trigger of 2s. (for example). For that, change the app-specification file and add a trigger: 
on_interval: 2s
. If you program stops, then the device will go to deep sleep and reset its memory. When it then starts fresh it should have enough memory to do the connection and run the loop. If there is another crash at some point it should then go again into deep sleep and then start fresh again. At least that's my hope. (You can obviously play around with the max-offline and the interval time.
k
You have a guide or something like that, for easy migration?
f
Depends a lot on how you use v1. For example whether you use pubsub or not. If you send me a description (or even the configuration/sources) I could have a look at it tomorrow. (florian@toit.io).
k
We're using mqtt directly to Azure, the main concern is that our devices are remotely deployed, we don't have easy physical access to them. I'll send you details, app-code etc tomorrow.
f
Just realized I never answered for the migration part: We are working on a tool to migrate from v1 to v2. It's a "best effort" mechanism, and we can't guarantee that devices will manage to upgrade without losing connection. It involves modifying the partition table on the device and if things go wrong, this can be "fatal". We are soon starting to test it on our test devices, and once that looks stable we will invite more users to test it.
PreviousNext
Powered by