Skip to main content

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

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



Back to the top