Description of problem: ==23239== 24 bytes in 1 blocks are definitely lost in loss record 102 of 282 ==23239== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==23239== by 0x38EAD0C77F: __vasprintf_chk (vasprintf_chk.c:80) ==23239== by 0x38EAD0C651: __asprintf_chk (asprintf_chk.c:33) ==23239== by 0x38F0804F98: magic_getpath (stdio2.h:178) ==23239== by 0x38F08083C3: file_apprentice (apprentice.c:359) ==23239== by 0x38F08050FF: magic_load (magic.c:298) ==23239== by 0x4C9373C: guestfs__file_architecture (filearch.c:203) ==23239== by 0x4C3F929: guestfs_file_architecture (actions-2.c:354) ==23239== by 0x4394C1: test_file_architecture_10 (tests.c:36656) ==23239== by 0x40DF43: main (tests.c:39885) (This is from a library which does magic_open, magic_load, magic_close.) Version-Release number of selected component (if applicable): file-5.11-8.fc19.x86_64 How reproducible: 100% Steps to Reproduce: I don't have a specific reproducer for this, but the bug is pretty obvious from looking at the code. In the function get_default_magic there's a static pointer to a string allocated by asprintf which is not freed unless you call the same function a second time. In fact, that code is pretty bizarre all round.
Looking at that function further, I highly doubt it's thread-safe, which is a problem since we're calling it from multithreaded programs.
libmagic is not thread-safe and yes, the code is strange in some places. I presume it's because it's older than me :). Are you able to reproduce it with simpler reproducer which does not use threads? There are discussions about libmagic vs. threads on file mailing list from time to time and I have feeling that upstream does not want to change to code a lot to make libmagic thread-safe...
(In reply to comment #2) > libmagic is not thread-safe and yes, the code is strange in some places. I > presume it's because it's older than me :). Are you able to reproduce it > with simpler reproducer which does not use threads? The memory leak is nothing to do with threads. Here's a reproducer: #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <magic.h> int main () { int r; magic_t m; m = magic_open (MAGIC_ERROR|MAGIC_RAW); if (!m) { perror ("magic_open"); exit (EXIT_FAILURE); } r = magic_load (m, NULL); if (r == -1) { perror ("magic_load"); exit (EXIT_FAILURE); } magic_close (m); exit (EXIT_SUCCESS); } gcc -Wall -g test.c -o test -lmagic valgrind --leak-check=full ./test By the way, I've discovered that this leak only occurs in Rawhide, not in Fedora 18. > There are discussions about libmagic vs. threads on file mailing list from > time to time and I have feeling that upstream does not want to change to > code a lot to make libmagic thread-safe... That's a big problem. We'll probably have to look at removing use of libmagic.
Thanks, I have just fixed it in rawhide.
downstream commit: http://pkgs.fedoraproject.org/cgit/rpms/file.git/commit/?id=79ee98fc