guild icon
Toit
#Exception Error: Malloc Failed
Thread channel in help
Koirin
Koirin 07/21/2023 10:05 AM
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.
floitsch
floitsch 07/22/2023 11:44 AM
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, ...)
Koirin
Koirin 07/23/2023 12:40 AM
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
Koirin
Koirin 07/23/2023 12:41 AM
It fails at the tls-handshake
floitsch
floitsch 07/23/2023 10:19 AM
I missed the second picture...
Yes. That's clearly v1.
floitsch
floitsch 07/23/2023 10:25 AM
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.
🙏1
Koirin
Koirin 07/23/2023 11:14 AM
You have a guide or something like that, for easy migration?
floitsch
floitsch 07/23/2023 11:16 AM
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. ([email protected]).
Koirin
Koirin 07/23/2023 02:16 PM
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.
KoirinOPKoirin
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 tom...
floitsch
floitsch 08/08/2023 05:13 PM
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.
10 messages in total