|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
Back to the top