I'm getting an OUT OF MEMORY error when using MQTT...
# helpp
PeterJ
05/27/2023, 9:40 AMWhen the message payload have been delivered to the IoT Hub and I close the connection using client.close, I get the following OUT OF MEMOTY error constantly:
OUT OF MEMORY error.
0: out_of_memory_ /core/exceptions.toit:195:1
1: Map.remove /core/collections.toit:2474:17
2: HashedInsertionOrderedCollection_.remove /core/collections.toit:1936:5
3: RpcSynchronizer_.send. /rpc/rpc.toit:66:11
4: __Monitor__.locked_. /core/monitor_impl.toit:123:12
5: __Monitor__.locked_ /core/monitor_impl.toit:95:3
6: RpcSynchronizer_.send /rpc/rpc.toit:53:3
7: Rpc.invoke. /rpc/rpc.toit:30:21
8: Rpc.invoke /rpc/rpc.toit:32:52
9: invoke /rpc/rpc.toit:8:23
10: TcpSocketImpl_.write /net/impl.toit:132:15
11: Session.flush_outgoing_ /tls/session.toit:199:25
12: Session.write /tls/session.toit:145:9
...
28: Connection_.write /full_client.toit:153:14
29: FullClient.disconnect_.. /full_client.toit:907:23
30: Mutex.do. /monitor.toit:24:27
31: __Monitor__.locked_. /core/monitor_impl.toit:123:12
32: __Monitor__.locked_ /core/monitor_impl.toit:95:3
33: Mutex.do /monitor.toit:24:3
34: FullClient.disconnect_. /full_client.toit:905:19
35: Mutex.do. /monitor.toit:24:27
36: __Monitor__.locked_. /core/monitor_impl.toit:123:12
37: __Monitor__.locked_ /core/monitor_impl.toit:95:3
38: Mutex.do /monitor.toit:24:3
39: FullClient.disconnect_ /full_client.toit:899:14
40: FullClient.close /full_client.toit:883:19
41: Client.close /client.toit:214:13
PeterJ
05/27/2023, 9:43 AMAlso getting this error and a subsequent reset: Reset after exiting deep sleep mode. crashes=2 out-of-memory=1
f
floitsch
05/27/2023, 9:43 AMIt seems to happen during the disconnect.
p
PeterJ
05/27/2023, 9:43 AMYes, I think so
f
floitsch
05/27/2023, 9:44 AMA clean close sends a disconnect packet which seems to lead to this situation.
Could you maybe try a forced close, just to see if that changes anything?
floitsch
05/27/2023, 9:45 AMclose --forcefloitsch
05/27/2023, 9:45 AMIn that case it doesn't notify the other side of the closing down.
p
PeterJ
05/27/2023, 9:45 AMChecking
PeterJ
05/27/2023, 9:47 AMThat did the trick. Just slam the door shut
f
floitsch
05/27/2023, 9:47 AMClearly not the right solution, but hopefully unblocks you.
floitsch
05/27/2023, 9:48 AMCould you maybe tag the current broken one, so we can investigate?
If you could send us a repro that would be ideal.
p
PeterJ
05/27/2023, 9:49 AMNot the nicest way to do it, but it works. I will send you the code and the deviceId so you can have a look at it if you want?
f
floitsch
05/27/2023, 9:49 AMThat would be great!
floitsch
05/27/2023, 9:49 AMBasically anything that allows me to reproduce it locally
floitsch
05/27/2023, 9:50 AMI don't think I will have the time over the weekend, but early next week.
p
PeterJ
05/27/2023, 9:52 AMIt's in your inbox now
PeterJ
05/27/2023, 9:53 AMThanks mate
k
kasperl
05/27/2023, 10:40 AMThis might work considerably better on Toit v2.
kasperl
05/27/2023, 10:40 AMWe have optimized the memory consumption of TLS connections a lot.
f
floitsch
05/27/2023, 10:58 AMI was already thinking the same thing. Might be worth trying on v2 first before I spend time debugging.
floitsch
05/27/2023, 11:00 AMAnother thing to try might be delaying the close a bit. Might be that there is already data queued and the disconnect request is just too much. By waiting the queued data could be offloaded and the disconnect would then work.
p
PeterJ
05/27/2023, 11:16 AMCan I migrate to version 2 by now?
f
floitsch
05/27/2023, 11:19 AMI think it's a good time to start migrating.
p
PeterJ
05/27/2023, 11:21 AMOkay, then we just need to plan it so I can get started on it