Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] List * handles passed as NULL in MQTTAsync.c

Sure this was taken directly from one of the examples (and modified for ssl) it was exhibiting the same issue:

int main(int argc, char* argv[])
    MQTTClient client;
    MQTTClient_connectOptions conn_opts = MQTTClient_connectOptions_initializer;
    int rc;
    int ch;
    MQTTClient_SSLOptions sslOpts = MQTTClient_SSLOptions_initializer;

    conn_opts.ssl = &sslOpts;
    sslOpts.trustStore = "/etc/ssl/certs/StartCom_Certification_Authority.pem";

    MQTTClient_create(&client, ADDRESS, "serial123", MQTTCLIENT_PERSISTENCE_NONE, NULL);

    conn_opts.keepAliveInterval = 20;
    conn_opts.cleansession = 1;
    conn_opts.username= "serial123";

    MQTTClient_setCallbacks(client, NULL, connlost, msgarrvd, delivered);

    if ((rc = MQTTClient_connect(client, &conn_opts)) != MQTTCLIENT_SUCCESS)
        printf("Failed to connect, return code %d\n", rc);
    printf("Subscribing to topic %s as %s\nfor QoS %d\n\n"
           "Press Q<Enter> to quit\n\n", argv[1],conn_opts.username, QOS);
    MQTTClient_subscribe(client, argv[1], QOS);

        ch = getchar();
    } while(ch!='Q' && ch != 'q');

    MQTTClient_disconnect(client, 10000);
    return rc;

From: paho-dev-bounces@xxxxxxxxxxx [paho-dev-bounces@xxxxxxxxxxx] on behalf of Ian Craggs [icraggs@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, April 25, 2014 8:08 AM
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] List * handles passed as NULL in  MQTTAsync.c

Hi Jimmy,

can I have a snippet of your application code to show how you are using
the client library?


On 04/24/2014 11:36 PM, Jimmy Johnson wrote:
> Hi Ian,
> I found another possible bug in the C code, and created a possible fix.  Here is what I found:
> My client was making a call to MQTTClient_create() in MQTTClient.c which initalizes it's static instance of the "handles" pointer. When the client actually published a message it was calling an instance of Protocol_processPublication which is located in MQTTAsync.c and using the instance of the static "handles" pointer in that file which had never been initalized since I had originally call MQTTClient_create() in MQTTClient.c to set up the client.  This caused a segfault when it hit the ListFindItem method with handles set as NULL.
> Here is my stack trace:
> #0  0x4002e550 in ListFindItem (aList=0x0, content=0x3c68c,
>      callback=0x40035b48 <clientStructCompare>) at src/LinkedList.c:154
> #1  0x40035ff0 in Protocol_processPublication (publish=0x306bc,
>      client=0x3c68c) at src/MQTTAsync.c:1809
> #2  0x400403e8 in MQTTProtocol_handlePublishes (pack=0x306bc, sock=6)
>      at src/MQTTProtocolClient.c:275
> #3  0x400e5e2c in MQTTClient_cycle (sock=0x41616db4, timeout=1000,
>      rc=0x41616db8) at src/MQTTClient.c:1508
> #4  0x400e24c4 in MQTTClient_run (n=0x3c4fc) at src/MQTTClient.c:483
> #5  0x40189910 in start_thread () from /lib/
> #6  0x405913ec in clone () from /lib/
> You can see that aList which is a List * is being passed in as NULL (0x0) to ListFindItem after being called from MQTTAsync.c
> My fix was to add a parameter to Protocol_processPublication called handles for both MQTTAsync.c and MQTTClient.c files.
> So
> void Protocol_processPublication(Publish* publish, Clients* client)
> becomes:
> void Protocol_processPublication(Publish* publish, Clients* client, List * handles)
> I then re factored calling methods to include their instance of the handle when making this call.  It seemed to fix everything since the call is no longer relying on a global variable. Oddly enough I did not see this issue when I was compiling and testing under Ubuntu 12.04 on my laptop.  It only started happening only when I cross compiled to my arm platform.  Do you think it will cause any issues?  I am using the library with c++, I don't know if that would make a difference.  I know the docs say that a synchronous client becomes asynchronous when you create callbacks for it, but it doesn't seem to initialize the asynchronous part of the code.
> Thanks for any insight you might have.
> Jimmy
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx

Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Committer on Paho, Mosquitto

paho-dev mailing list

Back to the top