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

Jimmy,

how did you build the library or program? MQTTAsync.c and MQTTClient.c are not meant to exist in the same program. You have to pick one library (paho-mqtt3c or paho-mqtt3a) or the other.

Ian


On 04/25/2014 07:32 PM, Jimmy Johnson wrote:
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.password="test";
     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);
         exit(-1);
     }
     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);

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

     MQTTClient_disconnect(client, 10000);
     MQTTClient_destroy(&client);
     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?

Ian

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/libpthread.so.0
#6  0x405913ec in clone () from /lib/libc.so.6

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
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Committer on Paho, Mosquitto

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev

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



Back to the top