-1

Trying to debug unhandled exception in MQTT Paho library. Can't figure out in which exact variable rises segmentation fault. Variables m and ma are not NULL. Not sure what does {...} means in m->c->connect_state.

How to know which exact variable raised the problem?

How to solve this problem?

enter image description here

Function code in MQTTClient.c:

int MQTTClient_setCallbacks(MQTTClient handle, void* context, MQTTClient_connectionLost* cl,
                                                        MQTTClient_messageArrived* ma, MQTTClient_deliveryComplete* dc)
{
    int rc = MQTTCLIENT_SUCCESS;
    MQTTClients* m = handle;

    FUNC_ENTRY;
    Thread_lock_mutex(mqttclient_mutex);

    if (m == NULL || ma == NULL || m->c->connect_state != NOT_IN_PROGRESS)
        rc = MQTTCLIENT_FAILURE;
    else
    {
        m->context = context;
        m->cl = cl;
        m->ma = ma;
        m->dc = dc;
    }

    Thread_unlock_mutex(mqttclient_mutex);
    FUNC_EXIT_RC(rc);
    return rc;
}

This code is from official Paho library: https://github.com/eclipse/paho.mqtt.c/blob/master/src/MQTTClient.c And why they make such assignment: MQTTClients* m = handle;

vico
  • 17,051
  • 45
  • 159
  • 315
  • 3
    Most likely `m->c` is null or invalid, or `m` is not null but pointing somewhere invalid (dangling, uninitialized, etc.) – Fred Larson Nov 24 '21 at 19:26
  • 3
    Given some `MQTTClient handle` then `MQTTClients* m = handle;` is invalid C. Unless `MQTTClients` (with s) is some exotic type. If this isn't a typo then these are incredibly poor type names. – Lundin Nov 24 '21 at 19:30
  • Perhaps the debugger shows `{...}` because it doesn't *know* the value due to the error. – Weather Vane Nov 24 '21 at 19:30
  • Also what's this macro crap doing `FUNC_ENTRY;`? Get rid of magic mysterious macros so that the code can be read and debugged by C programmers... – Lundin Nov 24 '21 at 19:33
  • This code is from official Paho library: https://github.com/eclipse/paho.mqtt.c/blob/master/src/MQTTClient.c Have no idea about: `MQTTClients* m = handle;` – vico Nov 24 '21 at 20:00
  • 2
    Please do not post images of code, post the actual text and format it properly. Images are really hard to read, and impossible to search or for people that use screen readers. – hardillb Nov 24 '21 at 20:02
  • I found this in the Github. `typedef void* MQTTClient;` This seems to be a sloppy library. Anyway, that explains why the cast silently works. But it also means that `MQTTClient_setCallbacks` must be called with a valid `MQTTClients` object passed as first parameter. Otherwise you'll get seg faults. – Lundin Nov 25 '21 at 09:50

1 Answers1

0

How to know which exact variable raised the problem?

Replace

if (m == NULL || ma == NULL || m->c->connect_state != NOT_IN_PROGRESS)
    rc = MQTTCLIENT_FAILURE;

temporarily with

if (m == NULL)
    rc = MQTTCLIENT_FAILURE;

else if (ma == NULL)
    rc = MQTTCLIENT_FAILURE;

else if (m->c->connect_state != NOT_IN_PROGRESS)
    rc = MQTTCLIENT_FAILURE;

Now you can see which variable is causing the problems.

klutt
  • 30,332
  • 17
  • 55
  • 95
  • got problem with `m->c->connect_state` since the fact that MQTTClient was not created at all. More details in [Segmentation fault while MQTTClient_setCallbacks](https://stackoverflow.com/questions/70108837/segmentation-fault-while-mqttclient-setcallbacks) – vico Nov 27 '21 at 10:02