This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-15. For the latest, interactive version please visit https://mariadb.com/kb/.

Memory leak in ma_net.c

Hey our LSan run identified a memory leak in ma_net.c file. The memory allocated on line 311 is not freed when the function returns on line 340.

You should add this code before returning "ma_net_real_write" on line 340:

#ifdef HAVE_COMPRESS
  if (net->compress)
    free((char*) packet);
#endif

This is what the LSan callstack looks like:

Direct leak of 102 byte(s) in 6 object(s) allocated from:

  1. 0 0x7f92a113ab78 in malloc /home/fcm/Perforce/SDK/UnixClang/dev/scripts/llvm_RELEASE_401_source/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66
  2. 1 0x7f92a0383b55 in ma_net_real_write /mariadb-connector-c-3.0.6-src/libmariadb/ma_net.c:311
  3. 2 0x7f92a0383c57 in ma_net_flush /mariadb-connector-c-3.0.6-src/libmariadb/ma_net.c:166
  4. 3 0x7f92a0383fd8 in ma_net_write_command /mariadb-connector-c-3.0.6-src/libmariadb/ma_net.c:244
  5. 4 0x7f92a038b8ba in mthd_my_send_cmd /mariadb-connector-c-3.0.6-src/libmariadb/mariadb_lib.c:395
  6. 5 0x7f92a0392736 in net_stmt_close /mariadb-connector-c-3.0.6-src/libmariadb/mariadb_stmt.c:1324
  7. 6 0x7f92a0393333 in mysql_stmt_close /mariadb-connector-c-3.0.6-src/libmariadb/mariadb_stmt.c:1344
  8. 7 0x7f92a03aa9c7 in mysql_stmt_close_start_internal /mariadb-connector-c-3.0.6-src/libmariadb/mariadb_async.c:1509
  9. 8 0x7f92a03aeda0 in my_context_spawn /mariadb-connector-c-3.0.6-src/libmariadb/ma_context.c:201

Can I get a better context on how we could be running into this issue? Are there any known workarounds ?(we are avoiding making a custom version of the package)

Answer Answered by Ian Gilfillan in this comment.

You should rather post this as a bug where the developers will notice it.

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.