IotMqtt reconnect crash (memory access violation in writeUTF)

Ask Questions B&R Software & Runtime
1

Hello,

I am using IotMqtt in a cyclic function block.

I added logic:

  • If TCP connection is lost → Enable = false
  • After a timer → Enable = true (reconnect)

This works, but if the connection drops multiple times quickly
(connect/disconnect/connect), the CPU crashes with a memory access violation.

The crash happens inside IotMqtt (internal functions, e.g. writeUTF).

I already check pointers:
if (inst->pMqttClient == NULL) return;

I call IotMqttClient() cyclically.

Question:
Is it safe to toggle Enable like this on connection loss?
Can fast reconnect cycles cause internal MQTT memory issues?

2

Hi @Ayman6855 ,
Welcome to the Community!
I don’t think we have a standard library for IotMqtt so theoretically we don’t support user library, but we can help you on troubleshooting.
Basic questions:

  1. Which AS are you using?

  2. Which runtime version?

  3. We need more information about that library, maybe someone in the Community already used that

  4. Could you upload SystemDump?

  5. Have you already checked the other posts we have for similar topic:

    image
    image993×387 27.2 KB

    Thanks
    Ciao
    Valerio

3

Hi

Hello,

thank you for your response.

I am using:

  • Automation Studio 4.12
  • Runtime 4.93

This is not a standard library, it was developed externally.

I will upload:

  • SystemDump
  • IotMqttLog.txt

The issue occurs during reconnect when the connection drops multiple times quickly.
The CPU crashes with a memory access violation inside IotMqtt (e.g. writeUTF).

I have already checked similar posts, but could not find a clear solution.

Any suggestions where to look further would be very helpful.

grafik
grafik870×510 36.8 KB

Systemdump.txt (396.9 KB)

IotMqttLog.txt (3.3 MB)

4

From the systemdump and logging you are using the GitHub - br-automation-community/paho.mqtt.c-ar: MQTT Client for Automation Runtime based on eclipse/paho.mqtt.c · GitHub

The MQTT implementation has an own retry and reconnecting build in. So you should not enable/disable the FUB all the time. In the configuration structure you should find the “AutomaticReconnect” which is default on TRUE.
When on FALSE you could also self use the “Connect” input on the Fub.

5

Any update @Ayman6855 ?
Thanks
Ciao
Valerio

6

@job.franken thank you for your explanation.

I have now set AutomaticReconnect = FALSE, but the problem still remains.

When the Ethernet cable is unplugged, it takes a long time until the client detects the disconnect. During this time, the client may still report Connected = TRUE, but no data is exchanged anymore.

Because of that, my function block monitors the MQTT activity (publish/subscribe). If no data is received or sent for a certain time, I trigger a manual reconnect.

I also noticed that using only Connect = FALSE/TRUE is often too slow or stays in the disconnecting state for a long time.

A fast and stable reconnect currently only works if I fully restart the FUB using Enable = FALSE → TRUE, especially when the Ethernet cable is unplugged and plugged in again quickly or multiple times.

My goal is to achieve a fast and reliable reconnect after physical link interruptions (Ethernet cable unplug/plug), without causing crashes or inconsistent states.

7

I did some digging.

WriteUTF is used in the basic part of the MQTT lib in the MQTTPacket_send_subscribe function and other send locations.
/**
Writes a “UTF” string to an output buffer. Converts C string to length-delimited.
@param pptr pointer to the output buffer - incremented by the number of bytes used & returned
@param string the C string to write
/
void writeUTF(char* pptr, const char* string)

The MQTT is starting a thread to handle all things my guess is that a quick disable/enable already deletes the memory of the thread while its actively is being used. (While some code exists in the fub to counter that . but guess its not 100% proof)

What times did you configure for the maxRetryInterval and ConnectTimeout etc ?

You still could put data in the que while the connection is not working or recovered. The data is then send in one go ones it is restored.

8

The three timers (MaxRetryInterval, MinRetryInterval, ConnectTimeout) are currently set to 0.

Could this be the reason for the issue?
The problem happens randomly, especially when the Ethernet cable is unplugged and plugged in multiple times in a row.

9

I would suggest to enter realistic (few seconds ? ) values and check if the automatic recovery then works.