-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MQTTProtocol_emptyMessageList() crashes due to null pointer assignment #1532
Comments
Anyone else run into this issue I saw it the other day and was wondering if anyone else had encounter this before I'm trying to migrate over to the MQTTAsync client library in hopes to get around some memory freeing issues that seem to occur occasionally |
the similar issue i am also facing, where sometimes when performing connection stress testing like low signal strength or network on off at that time double free crash is happening in MQTTProtocol_removePublication() during reconnect. below is backtrace for the same, #5 0x0000007f7d94c000 in malloc_printerr (str=str@entry=0x7f7da0fe00 "double free or corruption (!prev)") at malloc.c:5659 MQTT PAHO Version is 1.3.13 |
Describe the bug
Within the function
MQTTProtocol_emptyMessageList()
inMQTTProtocolClient.c
when the function attempts to assign the variableMessages* m
tocurrent->content
it is attempting to assign a null pointer and it crashes.When the stack trace for the segmentation fault is viewed this call to
MQTTProtocol_emptyMessageList()
occurs due to a previous call handled in the system toMQTTClient_destroy()
. It appears to be having trouble freeing the inbound message list for the client getting destroyed.For our project we brought in the repository as a submodule and are using the source code of PAHO to handle our MQTT logic. All of our business logic is handled on one thread while all of the MQTT logic is handled on the second thread.
Additional Information
To Reproduce
When performing network stress tests of the system that receives a message from the broker every 1000ms and responds to it, this behavior is seen when a device in our application has it's connection loss leading us to destroy the previously existing client. This failure does not occur for every call to
MQTTClient_destroy()
however it is more likely to appear the longer the stress test runs.Expected behavior
Application behaves as normal without unexpected crashing
Screenshots
Stack trace of the segmentation fault:
Value of
msgList
within the function causing the segmentation fault (size appears unreasonable):Log files
NewestGdbDump.txt
Environment:
The text was updated successfully, but these errors were encountered: