Help save net neutrality! Learn more.

[libuuid] memory leak on uuid_generate_time

Qier LU
  • Qier LU

    Qier LU - 2012-11-26

    Yes, I did research before asking.

    I wrote a simple program to test uuid_generate_time:

    #include <stdio.h>
    #include <uuid/uuid.h>
    // filename: uuidgen.c
    int main (int argc, char **argv)
      uuid_t u;
      char s_uuid[37];
      // uuid_generate (u);
      uuid_generate_time (u);
      uuid_unparse (u, s_uuid);
      fprintf (stdout, "%s\n", s_uuid);
      return 0;

    Compile it with:

    gcc uuidgen.c -luuid -Wall -o uuidgen

    Then run it with valgrind:

    valgrind --leak-check=full --show-reachable=yes ./uuidgen

    But valgrind complains for memory leaking:

    ==12946== Memcheck, a memory error detector
    ==12946== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
    ==12946== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
    ==12946== Command: ./uuidgen
    ==12946== HEAP SUMMARY:
    ==12946==     in use at exit: 568 bytes in 1 blocks
    ==12946==   total heap usage: 1 allocs, 0 frees, 568 bytes allocated
    ==12946== 568 bytes in 1 blocks are still reachable in loss record 1 of 1
    ==12946==    at 0x4C244E8: malloc (vg_replace_malloc.c:236)
    ==12946==    by 0x508FF84: fdopen@@GLIBC_2.2.5 (iofdopen.c:142)
    ==12946==    by 0x4E2B469: uuid__generate_time (in /lib/
    ==12946==    by 0x40065E: main (in /root/uuidgen)
    ==12946== LEAK SUMMARY:
    ==12946==    definitely lost: 0 bytes in 0 blocks
    ==12946==    indirectly lost: 0 bytes in 0 blocks
    ==12946==      possibly lost: 0 bytes in 0 blocks
    ==12946==    still reachable: 568 bytes in 1 blocks
    ==12946==         suppressed: 0 bytes in 0 blocks
    ==12946== For counts of detected and suppressed errors, rerun with: -v
    ==12946== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

    My libuuid version is 2.17.2 which is stable on Debian squeeze.

    Am I missing something?



  • Theodore Ts'o

    Theodore Ts'o - 2012-11-26

    Yes, it's a FILE * which is opened the first time the first time that a time-based UUID is generated, and which we keep open for speed reasons.   It's not a continual leak; think of it more as a static allocation -- the problem is valgrind can't tell the difference.   The point is that if you call uuid_generate_time() a million times, it's not like the amount of memory that gets used will increase, so it's really not an issue.

  • Qier LU

    Qier LU - 2012-11-27

    Thank you. It is nice.


Log in to post a comment.