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

mosquitto_loop_stop fails if called at the right time after mosquitto_disconnect #2905

Open
sdettmer opened this issue Sep 25, 2023 · 0 comments

Comments

@sdettmer
Copy link

Hi,

mosquitto-2.14.0 (I saw no related changes according to Changes).

I think I found a bug with an return code of mosquitto_loop_stop, I think in a "nothing to do" situation is erroneously returns MOSQ_ERR_INVAL.

If mosquitto is in threaded mode (mosquitto_loop_start() called before connect), then at shutdown applications must mosquitto_disconnect, and wait for disconnect callback and then call mosquitto_loop_stop, which sometimes fails.

With gdb, I saw that after disconnect the mosquitto_loop_forever() gets MOSQ_ERR_NO_CONN from mosquitto_loop (to not much surprise, since disconnect was called). In this case, loop_forever calls mosquitto__get_state() which is mosq_cs_disconnected, so run is set to zero, which ends both while (run) loops and returns to mosquitto__thread_main(). This (probably for another use case) does:

if(mosq->threaded == mosq_ts_self){
	mosq->threaded = mosq_ts_none;
}

and the thread ends.

If the main thread comes to call mosquitto_loop_stop after that, loop_stop finds mosq->threaded != mosq_ts_self and returns MOSQ_ERR_INVAL.

I think mosq->threaded is used to check if loop_stop needs to terminate an own thread (and here, it already ended, so it does not need to do so). but at least the return value is wrong.
However, at least if disconnect fails, I think the application must call mosquitto_loop_stop to ensure the thread is away.

NB: At the end there also is a difference, not sure if of importance if someone may connect again: if mosquitto_loop_stop won the race and was faster, mosq->thread_id is pthread_self (the thread from the application), but if disconnect / mosquitto__thread_main() won, it still seems to contain the thread_id of the non-existing mosquitto__thread_main() thread.

As a workaround, I think I can ignore MOSQ_ERR_INVAL from loop_stop, but I think this could be improved.

Also I wonder whether mosquitto_log_callback should be called with some messages if the thread_main exits, as this may be a very helpful information.

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

1 participant