In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed.
Closes#1793. Thanks to mbates14.
This fixes the following error, when compiling for systems without
pthread support, and when passing WITH_THREADING=no to make:
thread_mosq.c:24:12: fatal error: pthread.h: No such file or directory
# include <pthread.h>
^~~~~~~~~~~
compilation terminated.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
Fix clients not receiving messages after a previous client with the same client ID and positive will delay interval quit.
Closes#1752. Thanks to Jiří Zuzaňák.
keep v5 client read test to test for backwards compatability
adds username="usrname" and listener_port=1883 for v6 tests
Signed-off-by: david-beinder <david.beinder@mce.li>
From the FormatMessage() Win32 API documentation: "The lpBuffer
parameter is a pointer to an LPTSTR; you must cast the pointer
to an LPTSTR (for example, (LPTSTR)&lpBuffer)."
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage#parameters
This commit fixes warnings like these:
warning C4047: 'function': 'LPSTR' differs in levels of indirection from 'char **'
warning C4024: 'FormatMessageA': different types for formal and actual parameter 5
Signed-off-by: Sigmund Vik <sigmund_vik@yahoo.com>
This fixes Visual Studio compiler warnings like this one:
"warning C4003: not enough arguments for function-like
macro invocation 'G_MSGS_DROPPED_INC'"
Signed-off-by: Sigmund Vik <sigmund_vik@yahoo.com>
Before this commit there was no good way to detect that the
Mosquitto broker was done with its startup phase on systems
without systemd.
On such systems it was tricky to e.g. start the broker from
a test where ports are dynamically assigned and one have to
deal with potential port conflicts. Without a way to know
that the broker is done with its startup phase, there was no
way to know if the broker was able to acquire the port (for
both IPv4 and IPv6) without waiting for some unknown period
of time (when many tests are run in parallel a single process
might be starved for resources).
With this new broker ready message it is easy for the parent
process to monitor the broker output and figure out when the
port was successfully acquired.
Signed-off-by: Sigmund Vik <sigmund_vik@yahoo.com>