1

I was using libmysql in a project and I always see the exact leak summary 'still reachable: 73,944 bytes in 21 blocks' every time in Valgrind, which shouldn't be there. Later I tested this sample program from this link:

/* Simple C program that connects to MySQL Database server*/
#include <mysql.h>
#include <stdio.h>
main() {
   MYSQL *conn;
   MYSQL_RES *res;
   MYSQL_ROW row;
   char *server = "localhost";
   char *user = "root";
   char *password = "PASSWORD"; /* set me first */
   char *database = "mysql";
   conn = mysql_init(NULL);
   /* Connect to database */
   if (!mysql_real_connect(conn, server,
         user, password, database, 0, NULL, 0)) {
      fprintf(stderr, "%s\n", mysql_error(conn));
      exit(1);
   }
   /* send SQL query */
   if (mysql_query(conn, "show tables")) {
      fprintf(stderr, "%s\n", mysql_error(conn));
      exit(1);
   }
   res = mysql_use_result(conn);
   /* output table name */
   printf("MySQL Tables in mysql database:\n");
   while ((row = mysql_fetch_row(res)) != NULL)
      printf("%s \n", row[0]);
   /* close connection */
   mysql_free_result(res);
   mysql_close(conn);
}

When I run this with Valgrind, I'm still getting:

==22556== LEAK SUMMARY:
==22556==    definitely lost: 0 bytes in 0 blocks
==22556==    indirectly lost: 0 bytes in 0 blocks
==22556==      possibly lost: 0 bytes in 0 blocks
==22556==    still reachable: 73,944 bytes in 21 blocks
==22556==         suppressed: 0 bytes in 0 blocks
  1. Is this a cause for worry?
  2. Is this a bug in libmysql?
Zaxter
  • 2,939
  • 3
  • 31
  • 48
  • What happens if you run the code in a infinite loop, is the program memory usage increasing? – 2501 Oct 14 '14 at 07:09
  • I didn't try that, I'll try it now and update. – Zaxter Oct 14 '14 at 07:10
  • When run for 15 secs it gives [still reachable: 100,432 bytes in 30 blocks], for 1 min gives [still reachable: 108,768 bytes in 33 blocks]. Do you wan't me to run it for more time? – Zaxter Oct 14 '14 at 07:16
  • 1
    You can if you want to be sure, it is probably just memory fragmentation and allocator not releasing the memory back to the system. – 2501 Oct 14 '14 at 07:18

2 Answers2

1

"Still reachable" doesn't mean that there is a problem. From the horse's mouth:

"still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 1
    Found this on Valgrind's faq list on their website- "Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit of the program cause Valgrind to report this memory as still reachable. The behaviour not to free pools at the exit could be called a bug of the library though." Could this apply here? Is this possibly a bug in libmysql? – Zaxter Oct 14 '14 at 09:03
  • It is probably not a bug in libmysql. The other valgrind error classes are more important. – John Zwinck Oct 14 '14 at 09:14
1

After

mysql_close(conn);

call:

mysql_library_end()

Joe User
  • 11
  • 1
  • 1