Bug 919466

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