Skip to content
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

MQTTAsync_disconnect could return with success while disconnect command dropped #1454

Open
smallSwed opened this issue Feb 29, 2024 · 0 comments
Milestone

Comments

@smallSwed
Copy link

smallSwed commented Feb 29, 2024

Describe the bug
MQTTAsync_disconnect can return with success while the disconnect MQTTAsync_queuedCommand not inserted into the MQTTAsync_commands via MQTTAsync_addCommand if there are not enough memory. (like: memory constrained environment)

The caller of MQTTAsync_disconnect could be blocked indefinitly while waiting for the callbacks (onSuccess or onFailiure).

Source of the problem
After a bit of investigation I found one possible source for the problem inside MQTTAsyncUtils.c:
The MQTTAsync_addCommand calls the ListAppend in order to append the new disconnect command but does not check the return value to be not NULL (which is the case when the malloc fails for ListElement). In this case the content will be leaked and the disconnect never processed i.e. no callback called
The ListInsert call in MQTTAsync_addCommand has the same problem.

Expected behavior
A MQTTAsync_disconnect should return an error when the disconnect command is not queued.

Environment

  • OS: Windows 11
  • Version: paho.mqtt.c 1.3.12

Additional context
I was investigating a block on shutdown and the reason for the block was a signal not firing. In our execution of shutdown we try to disconnect via the async api:
0. set up option parameter with callbacks (e.g. onSuccess5)

  1. calling MQTTAsync_disconnect which returns no error
  2. the thread waits for a signal, which should be set/triggered when any of the callbacks options.onSuccess5 or options.onFailure5 are executed
  3. but neither onSuccess5 or onFailure5 called and the whole execution is blocked indefinitly (or for a very long time, I cannot be sure about this, there was a lot of traffic)
@icraggs icraggs added this to the 1.3.14 milestone Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants