Memory leaks #2057

przemyslawzygmunt · 2021-01-29T14:08:17Z

By running the server with valgrind you can find some memory leaks. I haven't looked at it closely yet. Perhaps it is just unclean memory when closing the process, but even if so, it is worth cleaning up to make it easier to track leaks that may actually occur. If I find a moment, I'll try to fix it.

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./mosquitto -c /etc/mosquitto/mosquitto.conf

==9570== Memcheck, a memory error detector
==9570== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9570== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==9570== Command: src/mosquitto -c /etc/mosquitto/mosquitto.conf
==9570==
^C==9570==
==9570== HEAP SUMMARY:
==9570== in use at exit: 140,570 bytes in 354 blocks
==9570== total heap usage: 117,182 allocs, 116,828 frees, 87,270,794 bytes allocated
==9570==
==9570== 15 bytes in 1 blocks are still reachable in loss record 1 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x4DE4DB9: strdup (strdup.c:42)
==9570== by 0x114017: context__init (context.c:76)
==9570== by 0x11D1F4: net__socket_accept (net.c:185)
==9570== by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570==
==9570== 16 bytes in 1 blocks are still reachable in loss record 2 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x40118B7: allocate_dtv_entry (dl-tls.c:582)
==9570== by 0x40118B7: allocate_and_init (dl-tls.c:607)
==9570== by 0x40118B7: tls_get_addr_tail.isra.0 (dl-tls.c:787)
==9570== by 0x40171F7: __tls_get_addr (tls_get_addr.S:55)
==9570== by 0x55ACC23: ???
==9570== by 0x559E2C6: ???
==9570== by 0x4014174: _dl_close_worker (dl-close.c:288)
==9570== by 0x4014174: _dl_close_worker (dl-close.c:111)
==9570== by 0x401486D: _dl_close (dl-close.c:842)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==9570== by 0x484F974: _dlerror_run (dlerror.c:163)
==9570== by 0x484F363: dlclose (dlclose.c:46)
==9570== by 0x12994D: security__module_cleanup_single.isra.0 (security.c:439)
==9570==
==9570== 19 bytes in 1 blocks are still reachable in loss record 3 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x1201A8: packet__read_binary (packet_datatypes.c:110)
==9570== by 0x12026E: packet__read_string (packet_datatypes.c:128)
==9570== by 0x1195B2: handle__connect (handle_connect.c:617)
==9570== by 0x120B19: packet__read (packet_mosq.c:515)
==9570== by 0x11CF04: loop_handle_reads_writes (mux_epoll.c:298)
==9570== by 0x11CF04: mux_epoll__handle (mux_epoll.c:210)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570==
==9570== 33 bytes in 1 blocks are still reachable in loss record 4 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x1201A8: packet__read_binary (packet_datatypes.c:110)
==9570== by 0x11961D: handle__connect (handle_connect.c:641)
==9570== by 0x120B19: packet__read (packet_mosq.c:515)
==9570== by 0x11CF04: loop_handle_reads_writes (mux_epoll.c:298)
==9570== by 0x11CF04: mux_epoll__handle (mux_epoll.c:210)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570== 64 bytes in 2 blocks are still reachable in loss record 5 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x40141BD: _dl_close_worker (dl-close.c:396)
==9570== by 0x40141BD: _dl_close_worker (dl-close.c:111)
==9570== by 0x401486D: _dl_close (dl-close.c:842)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==9570== by 0x484F974: _dlerror_run (dlerror.c:163)
==9570== by 0x484F363: dlclose (dlclose.c:46)
==9570== by 0x12994D: security__module_cleanup_single.isra.0 (security.c:439)
==9570== by 0x12A4B6: mosquitto_security_module_cleanup (security.c:452)
==9570== by 0x10E171: main (mosquitto.c:607)
==9570==
==9570== 73 bytes in 2 blocks are still reachable in loss record 6 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x401AAD9: strdup (strdup.c:42)
==9570== by 0x4016066: _dl_load_cache_lookup (dl-cache.c:317)
==9570== by 0x4008D0A: _dl_map_object (dl-load.c:2332)
==9570== by 0x400D291: openaux (dl-deps.c:64)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x400D605: _dl_map_object_deps (dl-deps.c:248)
==9570== by 0x401304F: dl_open_worker (dl-open.c:271)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570==
==9570== 73 bytes in 2 blocks are still reachable in loss record 7 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x400B58F: _dl_new_object (dl-object.c:163)
==9570== by 0x4005E47: _dl_map_object_from_fd (dl-load.c:1001)
==9570== by 0x4008A8C: _dl_map_object (dl-load.c:2466)
==9570== by 0x400D291: openaux (dl-deps.c:64)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x400D605: _dl_map_object_deps (dl-deps.c:248)
==9570== by 0x401304F: dl_open_worker (dl-open.c:271)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570==
==9570== 264 bytes in 1 blocks are still reachable in loss record 8 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x4012877: add_to_global (dl-open.c:104)
==9570== by 0x40134AF: dl_open_worker (dl-open.c:522)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==9570== by 0x484F974: _dlerror_run (dlerror.c:163)
==9570== by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==9570== by 0x12A120: security__module_init_single.isra.1 (security.c:311)
==9570== by 0x10DF8D: main (mosquitto.c:530)
==9570==
==9570== 624 bytes in 1 blocks are still reachable in loss record 9 of 18
==9570== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9570== by 0x113C0F: context__init (context.c:40)
==9570== by 0x11D1F4: net__socket_accept (net.c:185)
==9570== by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570== 1,174 bytes in 84 blocks are indirectly lost in loss record 10 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x4DE4DB9: strdup (strdup.c:42)
==9570== by 0x114017: context__init (context.c:76)
==9570== by 0x11D1F4: net__socket_accept (net.c:185)
==9570== by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570==
==9570== 1,680 bytes in 2 blocks are still reachable in loss record 11 of 18
==9570== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9570== by 0x4010A1F: _dl_check_map_versions (dl-version.c:274)
==9570== by 0x4013095: dl_open_worker (dl-open.c:277)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==9570== by 0x484F974: _dlerror_run (dlerror.c:163)
==9570== by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==9570== by 0x12A120: security__module_init_single.isra.1 (security.c:311)
==9570== by 0x10DF8D: main (mosquitto.c:530)
==9570==
==9570== 2,198 bytes in 84 blocks are indirectly lost in loss record 12 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x1201A8: packet__read_binary (packet_datatypes.c:110)
==9570== by 0x12026E: packet__read_string (packet_datatypes.c:128)
==9570== by 0x1195B2: handle__connect (handle_connect.c:617)
==9570== by 0x120B19: packet__read (packet_mosq.c:515)
==9570== by 0x11CF04: loop_handle_reads_writes (mux_epoll.c:298)
==9570== by 0x11CF04: mux_epoll__handle (mux_epoll.c:210)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570==
==9570== 2,381 bytes in 2 blocks are still reachable in loss record 13 of 18
==9570== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9570== by 0x400B2AD: _dl_new_object (dl-object.c:73)
==9570== by 0x4005E47: _dl_map_object_from_fd (dl-load.c:1001)
==9570== by 0x4008A8C: _dl_map_object (dl-load.c:2466)
==9570== by 0x400D291: openaux (dl-deps.c:64)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x400D605: _dl_map_object_deps (dl-deps.c:248)
==9570== by 0x401304F: dl_open_worker (dl-open.c:271)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570==
==9570== 2,772 bytes in 84 blocks are indirectly lost in loss record 14 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x1201A8: packet__read_binary (packet_datatypes.c:110)
==9570== by 0x11961D: handle__connect (handle_connect.c:641)
==9570== by 0x120B19: packet__read (packet_mosq.c:515)
==9570== by 0x11CF04: loop_handle_reads_writes (mux_epoll.c:298)
==9570== by 0x11CF04: mux_epoll__handle (mux_epoll.c:210)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570== 4,064 bytes in 1 blocks are still reachable in loss record 15 of 18
==9570== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9570== by 0x400A096: do_lookup_unique (dl-lookup.c:253)
==9570== by 0x400A096: do_lookup_x (dl-lookup.c:528)
==9570== by 0x400A38E: _dl_lookup_symbol_x (dl-lookup.c:814)
==9570== by 0x400BD5D: elf_machine_rela (dl-machine.h:308)
==9570== by 0x400BD5D: elf_dynamic_do_Rela (do-rel.h:137)
==9570== by 0x400BD5D: _dl_relocate_object (dl-reloc.c:258)
==9570== by 0x401319D: dl_open_worker (dl-open.c:377)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==9570== by 0x484F974: _dlerror_run (dlerror.c:163)
==9570== by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==9570==
==9570== 21,216 bytes in 34 blocks are indirectly lost in loss record 16 of 18
==9570== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9570== by 0x113C0F: context__init (context.c:40)
==9570== by 0x11D1F4: net__socket_accept (net.c:185)
==9570== by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570==
==9570== 58,560 (31,200 direct, 27,360 indirect) bytes in 50 blocks are definitely lost in loss record 17 of 18
==9570== at 0x4837B65: calloc (vg_replace_malloc.c:752)
==9570== by 0x113C0F: context__init (context.c:40)
==9570== by 0x11D1F4: net__socket_accept (net.c:185)
==9570== by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==9570== by 0x11C371: mosquitto_main_loop (loop.c:177)
==9570== by 0x10E088: main (mosquitto.c:565)
==9570==
==9570== 72,704 bytes in 1 blocks are still reachable in loss record 18 of 18
==9570== at 0x483577F: malloc (vg_replace_malloc.c:299)
==9570== by 0x5432455: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==9570== by 0x400F379: call_init.part.0 (dl-init.c:72)
==9570== by 0x400F475: call_init (dl-init.c:118)
==9570== by 0x400F475: _dl_init (dl-init.c:119)
==9570== by 0x40132D2: dl_open_worker (dl-open.c:517)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4012BB9: _dl_open (dl-open.c:599)
==9570== by 0x484F255: dlopen_doit (dlopen.c:66)
==9570== by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==9570== by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==9570== by 0x484F974: _dlerror_run (dlerror.c:163)
==9570== by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==9570==
==9570== LEAK SUMMARY:
==9570== definitely lost: 31,200 bytes in 50 blocks
==9570== indirectly lost: 27,360 bytes in 286 blocks
==9570== possibly lost: 0 bytes in 0 blocks
==9570== still reachable: 82,010 bytes in 18 blocks
==9570== suppressed: 0 bytes in 0 blocks
==9570==
==9570== For counts of detected and suppressed errors, rerun with: -v
==9570== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==9570== could not unlink /tmp/vgdb-pipe-from-vgdb-to-9570-by-pzygmunt-on-???
==9570== could not unlink /tmp/vgdb-pipe-to-vgdb-from-9570-by-pzygmunt-on-???
==9570== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-9570-by-pzygmunt-on-???

ralight · 2021-01-29T17:20:07Z

Could you give some details of what you were doing when this happened? I keep a good eye on valgrind, so I'm keen to find how this could be happening.

przemyslawzygmunt · 2021-01-29T17:27:57Z

I'm not doing anything special. I just started a server with one connection on port 1883 and a dozen connections on TLS 8883. Connections to 8883 mostly come from Home Assistant and a few other MQTT brokers. As I wrote before. If I find, I will try to precisely determine what causes the problems that valgrind reports.

ralight · 2021-01-29T19:24:37Z

I've just tried a single mosquitto_sub connected to 1883, plus a dozen to 8883, with this config:

istener 1883

listener 8883
cafile ../test/ssl/all-ca.crt
certfile ../test/ssl/server.crt
keyfile ../test/ssl/server.key

allow_anonymous true

My valgrind log was this:

==146688== Memcheck, a memory error detector
==146688== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==146688== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==146688== Command: ./mosquitto -c m.conf
==146688== Parent PID: 145500
==146688==
==146688==
==146688== HEAP SUMMARY:
==146688==     in use at exit: 0 bytes in 0 blocks
==146688==   total heap usage: 16,995 allocs, 16,995 frees, 6,741,739 bytes allocated
==146688==
==146688== All heap blocks were freed -- no leaks are possible
==146688==
==146688== For lists of detected and suppressed errors, rerun with: -s
==146688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

It looks like you are using a plugin, is that correct? It really is important to know as many details as possible about what you are doing so I can properly reproduce it. I could be making an assumption about configuration that is different to what you have.

przemyslawzygmunt · 2021-01-29T20:00:21Z

Yes, I have a dedicated plugin that I wrote. However, it is separately tested with valgrind and I did not detect any leaks there. I tried to remove everything from my plugin and left the following code:

#include "auth-plugin.h"
#include <mysql.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

mosq_plugin_EXPORT int mosquitto_auth_plugin_version(void) {
  return MOSQ_AUTH_PLUGIN_VERSION;
}

mosq_plugin_EXPORT int mosquitto_auth_plugin_init(void **user_data,
                                                  struct mosquitto_opt *opts,
                                                  int opt_count) {
  return MOSQ_ERR_SUCCESS;
}

mosq_plugin_EXPORT int mosquitto_auth_plugin_cleanup(void *user_data,
                                                     struct mosquitto_opt *opts,
                                                     int opt_count) {
  return MOSQ_ERR_SUCCESS;
}

mosq_plugin_EXPORT int mosquitto_auth_security_init(void *user_data,
                                                    struct mosquitto_opt *opts,
                                                    int opt_count,
                                                    bool reload) {
  return MOSQ_ERR_SUCCESS;
}

mosq_plugin_EXPORT int mosquitto_auth_security_cleanup(
    void *user_data, struct mosquitto_opt *opts, int opt_count, bool reload) {
  return MOSQ_ERR_SUCCESS;
}

mosq_plugin_EXPORT int mosquitto_auth_unpwd_check(void *user_data,
                                                  struct mosquitto *client,
                                                  const char *username,
                                                  const char *password) {
  return MOSQ_ERR_SUCCESS;
}

mosq_plugin_EXPORT int mosquitto_auth_acl_check(
    void *user_data, int access, struct mosquitto *client,
    const struct mosquitto_acl_msg *msg) {

        return MOSQ_ERR_SUCCESS;
}

mosq_plugin_EXPORT int mosquitto_auth_psk_key_get(void *user_data,
                                                  struct mosquitto *client,
                                                  const char *hint,
                                                  const char *identity,
                                                  char *key, int max_key_len) {
  return MOSQ_ERR_AUTH;
}

Compilation:

make all
Building file: ../src/auth-plugin.c
Invoking: Cross GCC Compiler
gcc -I../src -I/usr/include/mariadb -O0 -g3 -Wall -c -fmessage-length=0 -fPIC -MMD -MP -MF"src/auth-plugin.d" -MT"src/auth-plugin.o" -o "src/auth-plugin.o" "../src/auth-plugin.c"
Finished building: ../src/auth-plugin.c

Building target: libsupla-mosquitto-auth-plugin.so
Invoking: Cross G++ Linker
g++ -shared -o "libsupla-mosquitto-auth-plugin.so" ./src/auth-plugin.o -lmariadb
Finished building target: libsupla-mosquitto-auth-plugin.so

/etc/mosquitto/mosquitto.conf

persistence false
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

/etc/mosquitto/conf.d/supla.conf

user mosquitto

connection_messages true
#log_type debug

max_queued_messages 1000
sys_interval 30
max_qos 2

allow_anonymous false
allow_zero_length_clientid false
listener 1883 localhost
listener 8883 
message_size_limit 1024

persistence false

auth_plugin /lib/x86_64-linux-gnu/libsupla-mosquitto-auth-plugin.so
auth_opt_supla_server_username *****
auth_opt_supla_server_password *****
auth_opt_supla_server_client_extra_ip *****
auth_opt_mysql_password *****

certfile /etc/ssl/certs/ssl-cert-wildcard-supla.pem
cafile /etc/ssl/certs/rootca.crt
keyfile /etc/ssl/private/ssl-cert-wildcard-supla.key

Mosquitto built with the following parameters:

make all WITH_MEMORY_TRACKING=no WITH_BRIDGE=no WITH_DOCS=no WITH_CJSON=no

The result of valgrind:

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./src/mosquitto -c /etc/mosquitto/mosquitto.conf
==17678== Memcheck, a memory error detector
==17678== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17678== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==17678== Command: ./src/mosquitto -c /etc/mosquitto/mosquitto.conf
==17678==
1611949704: Loading config file /etc/mosquitto/conf.d/supla.conf
^C==17678==
==17678== HEAP SUMMARY:
==17678==     in use at exit: 81,319 bytes in 14 blocks
==17678==   total heap usage: 10,704 allocs, 10,690 frees, 2,165,706 bytes allocated
==17678==
==17678== 16 bytes in 1 blocks are still reachable in loss record 1 of 9
==17678==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17678==    by 0x40118B7: allocate_dtv_entry (dl-tls.c:582)
==17678==    by 0x40118B7: allocate_and_init (dl-tls.c:607)
==17678==    by 0x40118B7: tls_get_addr_tail.isra.0 (dl-tls.c:787)
==17678==    by 0x40171F7: __tls_get_addr (tls_get_addr.S:55)
==17678==    by 0x55ACC23: ???
==17678==    by 0x559E2C6: ???
==17678==    by 0x4014174: _dl_close_worker (dl-close.c:288)
==17678==    by 0x4014174: _dl_close_worker (dl-close.c:111)
==17678==    by 0x401486D: _dl_close (dl-close.c:842)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==17678==    by 0x484F974: _dlerror_run (dlerror.c:163)
==17678==    by 0x484F363: dlclose (dlclose.c:46)
==17678==    by 0x12994D: security__module_cleanup_single.isra.0 (security.c:439)
==17678==
==17678== 64 bytes in 2 blocks are still reachable in loss record 2 of 9
==17678==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17678==    by 0x40141BD: _dl_close_worker (dl-close.c:396)
==17678==    by 0x40141BD: _dl_close_worker (dl-close.c:111)
==17678==    by 0x401486D: _dl_close (dl-close.c:842)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==17678==    by 0x484F974: _dlerror_run (dlerror.c:163)
==17678==    by 0x484F363: dlclose (dlclose.c:46)
==17678==    by 0x12994D: security__module_cleanup_single.isra.0 (security.c:439)
==17678==    by 0x12A4B6: mosquitto_security_module_cleanup (security.c:452)
==17678==    by 0x10E171: main (mosquitto.c:607)
==17678==
==17678== 73 bytes in 2 blocks are still reachable in loss record 3 of 9
==17678==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17678==    by 0x401AAD9: strdup (strdup.c:42)
==17678==    by 0x4016066: _dl_load_cache_lookup (dl-cache.c:317)
==17678==    by 0x4008D0A: _dl_map_object (dl-load.c:2332)
==17678==    by 0x400D291: openaux (dl-deps.c:64)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x400D605: _dl_map_object_deps (dl-deps.c:248)
==17678==    by 0x401304F: dl_open_worker (dl-open.c:271)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678== 73 bytes in 2 blocks are still reachable in loss record 4 of 9
==17678==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17678==    by 0x400B58F: _dl_new_object (dl-object.c:163)
==17678==    by 0x4005E47: _dl_map_object_from_fd (dl-load.c:1001)
==17678==    by 0x4008A8C: _dl_map_object (dl-load.c:2466)
==17678==    by 0x400D291: openaux (dl-deps.c:64)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x400D605: _dl_map_object_deps (dl-deps.c:248)
==17678==    by 0x401304F: dl_open_worker (dl-open.c:271)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==
==17678== 264 bytes in 1 blocks are still reachable in loss record 5 of 9
==17678==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17678==    by 0x4012877: add_to_global (dl-open.c:104)
==17678==    by 0x40134AF: dl_open_worker (dl-open.c:522)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==17678==    by 0x484F974: _dlerror_run (dlerror.c:163)
==17678==    by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==17678==    by 0x12A120: security__module_init_single.isra.1 (security.c:311)
==17678==    by 0x10DF8D: main (mosquitto.c:530)
==17678==
==17678== 1,680 bytes in 2 blocks are still reachable in loss record 6 of 9
==17678==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==17678==    by 0x4010A1F: _dl_check_map_versions (dl-version.c:274)
==17678==    by 0x4013095: dl_open_worker (dl-open.c:277)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==17678==    by 0x484F974: _dlerror_run (dlerror.c:163)
==17678==    by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==17678==    by 0x12A120: security__module_init_single.isra.1 (security.c:311)
==17678==    by 0x10DF8D: main (mosquitto.c:530)
==17678==
==17678== 2,381 bytes in 2 blocks are still reachable in loss record 7 of 9
==17678==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==17678==    by 0x400B2AD: _dl_new_object (dl-object.c:73)
==17678==    by 0x4005E47: _dl_map_object_from_fd (dl-load.c:1001)
==17678==    by 0x4008A8C: _dl_map_object (dl-load.c:2466)
==17678==    by 0x400D291: openaux (dl-deps.c:64)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x400D605: _dl_map_object_deps (dl-deps.c:248)
==17678==    by 0x401304F: dl_open_worker (dl-open.c:271)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678== 4,064 bytes in 1 blocks are still reachable in loss record 8 of 9
==17678==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==17678==    by 0x400A096: do_lookup_unique (dl-lookup.c:253)
==17678==    by 0x400A096: do_lookup_x (dl-lookup.c:528)
==17678==    by 0x400A38E: _dl_lookup_symbol_x (dl-lookup.c:814)
==17678==    by 0x400BD5D: elf_machine_rela (dl-machine.h:308)
==17678==    by 0x400BD5D: elf_dynamic_do_Rela (do-rel.h:137)
==17678==    by 0x400BD5D: _dl_relocate_object (dl-reloc.c:258)
==17678==    by 0x401319D: dl_open_worker (dl-open.c:377)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==17678==    by 0x484F974: _dlerror_run (dlerror.c:163)
==17678==    by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==17678==
==17678== 72,704 bytes in 1 blocks are still reachable in loss record 9 of 9
==17678==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17678==    by 0x5432455: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==17678==    by 0x400F379: call_init.part.0 (dl-init.c:72)
==17678==    by 0x400F475: call_init (dl-init.c:118)
==17678==    by 0x400F475: _dl_init (dl-init.c:119)
==17678==    by 0x40132D2: dl_open_worker (dl-open.c:517)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4012BB9: _dl_open (dl-open.c:599)
==17678==    by 0x484F255: dlopen_doit (dlopen.c:66)
==17678==    by 0x4E91B2E: _dl_catch_exception (dl-error-skeleton.c:196)
==17678==    by 0x4E91BBE: _dl_catch_error (dl-error-skeleton.c:215)
==17678==    by 0x484F974: _dlerror_run (dlerror.c:163)
==17678==    by 0x484F2E5: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==17678==
==17678== LEAK SUMMARY:
==17678==    definitely lost: 0 bytes in 0 blocks
==17678==    indirectly lost: 0 bytes in 0 blocks
==17678==      possibly lost: 0 bytes in 0 blocks
==17678==    still reachable: 81,319 bytes in 14 blocks
==17678==         suppressed: 0 bytes in 0 blocks
==17678==
==17678== For counts of detected and suppressed errors, rerun with: -v
==17678== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==17678== could not unlink /tmp/vgdb-pipe-from-vgdb-to-17678-by-pzygmunt-on-???
==17678== could not unlink /tmp/vgdb-pipe-to-vgdb-from-17678-by-pzygmunt-on-???
==17678== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-17678-by-pzygmunt-on-???

Test carried out with considerably fewer connections (only 2). In this case, you can no longer see "definitely lost" but this may be related to less traffic.

przemyslawzygmunt · 2021-01-29T20:10:34Z

Linux **** 4.19.0-5-cloud-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux

ralight · 2021-01-30T20:50:14Z

The dlopen related blocks should be fixed, but they aren't critical due to just being a lack of freeing on exit. The definitely lost case though - that's important, are you able to reproduce it?

przemyslawzygmunt · 2021-01-30T21:10:25Z

I am aware of this, but it is more difficult to catch the right ones when there is a large number of logs. Leaks appear in my environment quite quickly as soon as I let in users. I will try to find the cause of the problem. Alternatively, I will try to dump the data that is sent to and from clients to a file.

ralight · 2021-01-30T21:44:47Z

You could always generate a suppression file for the dlopen functions: valgrind --leak-check=full --gen-suppressions=all --log-file=vglog

przemyslawzygmunt · 2021-01-30T22:43:43Z

Aside from topic... Did you run mosquitto with any fuzzer, for example https://lcamtuf.coredump.cx/afl/ ?

ralight · 2021-02-01T10:14:44Z

It's not something I have done, but others have done and found the odd potential memory leak. I'd be keen to have a fuzzing setup if someone wanted to help with that... :)

przemyslawzygmunt · 2021-02-01T10:52:09Z

I use AFL in my projects. I use this fuzzer to detect possible security vulnerabilities.
I don't know your code well enough, but maybe when I have some time it will try to adapt the mosquito to fuzzing.

ralight · 2021-02-01T11:59:56Z

I hope that this lot will make their tool available: https://www.mdpi.com/1424-8220/20/18/5194

przemyslawzygmunt · 2021-02-01T12:24:15Z

In my project, I extracted the logic responsible for handling the protocol into a separate project, which instead of reading data from the tcp socket, it reads it from the file. The compiled binary allows you to indicate the path to the file to which AFL generates mutated data. Of course, this doesn't test everything, but the essential part. For chamfering to be effective, the tested process must start very quickly.

Then I run several simultaneous tasks on a powerful machine. In my case, the command line looks like this

./afl-fuzz -i ./testcases/supla1 -o ./supla-out1 -S fuzzer01 -f /tmp/afl1.raw ../../supla-core/supla-afl/Debug/supla-afl /tmp/afl.raw

https://github.com/SUPLA/supla-core/blob/master/supla-afl/src/supla-afl.cpp

I think in your case you would have to build a separate project that uses libmosquitto except that libmosquitto would have to be read from a file instead of a socket.

przemyslawzygmunt · 2021-02-01T18:36:29Z

I was able to trace a TCP connection which is causing the leak below (all plugins off). I will try to dump the data that is being sent.

==4011== Memcheck, a memory error detector
==4011== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4011== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==4011== Command: ./src/mosquitto -c /etc/mosquitto/mosquitto.conf
==4011==
1612203606: Loading config file /etc/mosquitto/conf.d/supla.conf
^C==4011==
==4011== HEAP SUMMARY:
==4011==     in use at exit: 99,976 bytes in 122 blocks
==4011==   total heap usage: 73,433 allocs, 73,311 frees, 30,256,226 bytes allocated
==4011==
==4011== 18,657 (16,848 direct, 1,809 indirect) bytes in 27 blocks are definitely lost in loss record 12 of 13
==4011==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==4011==    by 0x113C0F: context__init (context.c:40)
==4011==    by 0x11D1F4: net__socket_accept (net.c:185)
==4011==    by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==4011==    by 0x11C371: mosquitto_main_loop (loop.c:177)
==4011==    by 0x10E088: main (mosquitto.c:565)
==4011==
==4011== LEAK SUMMARY:
==4011==    definitely lost: 16,848 bytes in 27 blocks
==4011==    indirectly lost: 1,809 bytes in 81 blocks
==4011==      possibly lost: 0 bytes in 0 blocks
==4011==    still reachable: 81,319 bytes in 14 blocks
==4011==         suppressed: 0 bytes in 0 blocks

przemyslawzygmunt · 2021-02-01T19:20:08Z

OK, I was able to reproduce the leak reported by valgrind.
This happens when we connect one broker to another. Master broker configuration (the one that reports the leak).

connection_messages true
max_queued_messages 1000
sys_interval 30
max_qos 2
allow_anonymous false
allow_zero_length_clientid false
listener 1883 localhost
listener 8883 
message_size_limit 1024
persistence false
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log

all plugins off

Local broker configuration:

connection bridge-xyzyuiop
address master:8883
topic supla/# in
topic homeassistant/# in
topic supla/+/devices/+/channels/+/execute_action out
topic supla/+/devices/+/channels/+/set/+ out
remote_username ****
remote_password ****
bridge_capath /etc/ssl/certs

The local broker keeps reconnecting because authorization fails. Stopping the master broker causes valgrind to report a leak.

==4011==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==4011==    by 0x113C0F: context__init (context.c:40)
==4011==    by 0x11D1F4: net__socket_accept (net.c:185)
==4011==    by 0x11CE61: mux_epoll__handle (mux_epoll.c:215)
==4011==    by 0x11C371: mosquitto_main_loop (loop.c:177)
==4011==    by 0x10E088: main (mosquitto.c:565)

In addition, I found minor leaks that are not dangerous but it is worth the broker initiation to be organized a little differently.
I mean exiting the program without cleaning up what was already initiated.
https://github.com/eclipse/mosquitto/blob/master/src/mosquitto.c#L551

In this case, if there is already a running process that blocks the ports on which the broker is to listen, it will exit the program with a leak as below.

==7458== Memcheck, a memory error detector
==7458== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7458== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==7458== Command: ./src/mosquitto -c /etc/mosquitto/mosquitto.conf
==7458==
1612207087: Loading config file /etc/mosquitto/conf.d/supla.conf
==7458==
==7458== HEAP SUMMARY:
==7458==     in use at exit: 225,650 bytes in 776 blocks
==7458==   total heap usage: 5,234 allocs, 4,458 frees, 457,142 bytes allocated
==7458==
==7458== 6 bytes in 1 blocks are definitely lost in loss record 3 of 83
==7458==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==7458==    by 0x4DE4DB9: strdup (strdup.c:42)
==7458==    by 0x11FE1D: mosquitto__strdup (memory_mosq.c:152)
==7458==    by 0x1168EE: config__check (conf.c:2282)
==7458==    by 0x1168EE: config__parse_args (conf.c:527)
==7458==    by 0x10DF15: main (mosquitto.c:494)
==7458==
==7458== 8 bytes in 1 blocks are definitely lost in loss record 6 of 83
==7458==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==7458==    by 0x11FC70: mosquitto__calloc (memory_mosq.c:58)
==7458==    by 0x130C5E: mosquitto_security_init_default (security_default.c:65)
==7458==    by 0x10DFCE: main (mosquitto.c:532)
==7458==
==7458== 10 bytes in 1 blocks are definitely lost in loss record 11 of 83
==7458==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==7458==    by 0x4DE4DB9: strdup (strdup.c:42)
==7458==    by 0x11FE1D: mosquitto__strdup (memory_mosq.c:152)
==7458==    by 0x111463: conf__parse_string (conf.c:2365)
==7458==    by 0x11592F: config__read_file_core (conf.c:2130)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x1138F7: config__read_file_core (conf.c:1334)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x115BC7: config__read (conf.c:626)
==7458==    by 0x1165CD: config__parse_args (conf.c:383)
==7458==    by 0x10DF15: main (mosquitto.c:494)
==7458== 20 bytes in 1 blocks are definitely lost in loss record 21 of 83
==7458==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==7458==    by 0x4DE4DB9: strdup (strdup.c:42)
==7458==    by 0x11FE1D: mosquitto__strdup (memory_mosq.c:152)
==7458==    by 0x111463: conf__parse_string (conf.c:2365)
==7458==    by 0x115091: config__read_file_core (conf.c:1766)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x115BC7: config__read (conf.c:626)
==7458==    by 0x1165CD: config__parse_args (conf.c:383)
==7458==    by 0x10DF15: main (mosquitto.c:494)
==7458==
==7458== 33 bytes in 1 blocks are definitely lost in loss record 44 of 83
==7458==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==7458==    by 0x4DE4DB9: strdup (strdup.c:42)
==7458==    by 0x11FE1D: mosquitto__strdup (memory_mosq.c:152)
==7458==    by 0x1142DC: config__read_file_core (conf.c:1526)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x115BC7: config__read (conf.c:626)
==7458==    by 0x1165CD: config__parse_args (conf.c:383)
==7458==    by 0x10DF15: main (mosquitto.c:494)
==7458==
==7458== 860 (736 direct, 124 indirect) bytes in 1 blocks are definitely lost in loss record 70 of 83
==7458==    at 0x4837D7B: realloc (vg_replace_malloc.c:826)
==7458==    by 0x11FDA2: mosquitto__realloc (memory_mosq.c:130)
==7458==    by 0x113C48: config__read_file_core (conf.c:1431)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x1138F7: config__read_file_core (conf.c:1334)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x115BC7: config__read (conf.c:626)
==7458==    by 0x1165CD: config__parse_args (conf.c:383)
==7458==    by 0x10DF15: main (mosquitto.c:494)
==7458==
==7458== 16,384 bytes in 1 blocks are possibly lost in loss record 80 of 83
==7458==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
==7458==    by 0x53732C8: ??? (in /usr/lib/x86_64-linux-gnu/libmariadb.so.3)
==7458==    by 0x5370460: ??? (in /usr/lib/x86_64-linux-gnu/libmariadb.so.3)
==7458==    by 0x536D2AF: mysql_real_connect (in /usr/lib/x86_64-linux-gnu/libmariadb.so.3)
==7458==    by 0x484653A: mysql_connect (auth-plugin.c:51)
==7458==    by 0x4846CA9: mosquitto_auth_plugin_init (auth-plugin.c:247)
==7458==    by 0x12D740: security__load_v4 (security.c:279)
==7458==    by 0x12D9F2: security__module_init_single.isra.1 (security.c:344)
==7458==    by 0x10DFBD: main (mosquitto.c:530)
==7458==
==7458== 19,453 (264 direct, 19,189 indirect) bytes in 1 blocks are definitely lost in loss record 81 of 83
==7458==    at 0x48356AF: malloc (vg_replace_malloc.c:298)
==7458==    by 0x4837DE7: realloc (vg_replace_malloc.c:826)
==7458==    by 0x11FDA2: mosquitto__realloc (memory_mosq.c:130)
==7458==    by 0x1127D3: config__read_file_core (conf.c:881)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x1138F7: config__read_file_core (conf.c:1334)
==7458==    by 0x115B12: config__read_file (conf.c:2205)
==7458==    by 0x115B12: config__read_file (conf.c:2172)
==7458==    by 0x115BC7: config__read (conf.c:626)
==7458==    by 0x1165CD: config__parse_args (conf.c:383)
==7458==    by 0x10DF15: main (mosquitto.c:494)
==7458==
==7458== LEAK SUMMARY:
==7458==    definitely lost: 1,077 bytes in 7 blocks
==7458==    indirectly lost: 19,313 bytes in 47 blocks
==7458==      possibly lost: 16,384 bytes in 1 blocks
==7458==    still reachable: 188,876 bytes in 721 blocks
==7458==         suppressed: 0 bytes in 0 blocks
==7458== Reachable blocks (those to which a pointer was found) are not shown.
==7458== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==7458==
==7458== For counts of detected and suppressed errors, rerun with: -v
==7458== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
==7458== could not unlink /tmp/vgdb-pipe-from-vgdb-to-7458-by-pzygmunt-on-???
==7458== could not unlink /tmp/vgdb-pipe-to-vgdb-from-7458-by-pzygmunt-on-???
==7458== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-7458-by-pzygmunt-on-???

Signed-off-by: Przemek Zygmunt <[email protected]>

przemyslawzygmunt added a commit to przemyslawzygmunt/mosquitto that referenced this issue Feb 1, 2021

Fixing a memory leak when another broker connects. Closes eclipse#2057

4136542

przemyslawzygmunt added a commit to przemyslawzygmunt/mosquitto that referenced this issue Feb 1, 2021

Fixing a memory leak when another broker connects. Closes eclipse#2057

e29bb1c

Signed-off-by: Przemek Zygmunt <[email protected]>

przemyslawzygmunt mentioned this issue Feb 2, 2021

Fixing a memory leak when another broker connects. Closes #2057 #2064

Closed

ralight added this to the 2.0.7 milestone Feb 3, 2021

ralight closed this as completed in 7a3b69f Feb 4, 2021

github-actions bot locked as resolved and limited conversation to collaborators Aug 11, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Memory leaks #2057

Memory leaks #2057

przemyslawzygmunt commented Jan 29, 2021

ralight commented Jan 29, 2021

przemyslawzygmunt commented Jan 29, 2021

ralight commented Jan 29, 2021

przemyslawzygmunt commented Jan 29, 2021

przemyslawzygmunt commented Jan 29, 2021 •

edited

ralight commented Jan 30, 2021

przemyslawzygmunt commented Jan 30, 2021

ralight commented Jan 30, 2021

przemyslawzygmunt commented Jan 30, 2021

ralight commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

ralight commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

Memory leaks #2057

Memory leaks #2057

Comments

przemyslawzygmunt commented Jan 29, 2021

ralight commented Jan 29, 2021

przemyslawzygmunt commented Jan 29, 2021

ralight commented Jan 29, 2021

przemyslawzygmunt commented Jan 29, 2021

przemyslawzygmunt commented Jan 29, 2021 • edited

ralight commented Jan 30, 2021

przemyslawzygmunt commented Jan 30, 2021

ralight commented Jan 30, 2021

przemyslawzygmunt commented Jan 30, 2021

ralight commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

ralight commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

przemyslawzygmunt commented Feb 1, 2021

przemyslawzygmunt commented Jan 29, 2021 •

edited