Valgrind oddity.

Adam D. Moss adam at
Fri Oct 8 10:42:11 EDT 2004


==22066== pthread_mutex_destroy: mutex is still in use
==22066==    at 0x1B982A3D: pthread_error (vg_libpthread.c:380)
==22066==    by 0x1B984D32: pthread_mutex_destroy (vg_libpthread.c:1369)
==22066==    by 0x1BB01D84: closedir (in /lib/
==22066==    by 0x80F6026: __PHYSFS_platformEnumerateFiles (posix.c:293)
==22066==    by 0x80F318B: DIR_enumerateFiles (dir.c:218)
==22066==    by 0x80F217C: PHYSFS_enumerateFiles (physfs.c:1489)
==22066==    by 0x80F184D: PHYSFS_setSaneConfig (physfs.c:1111)
==22066==    by 0x8052B9F: init_fileio (main.c:106)
==22066==    by 0x8053F49: main (main.c:833)

I've been noticing this for as long as I've been valgrinding,
but didn't know what to make of it.  It doesn't seem to have
caused me any harm but I thought it worth pointing out.

n.b. I've compiled physfs without pthreads support.  My app
doesn't use threads explicitly (it does use OpenAL which
implicitly uses threads, but OpenAL has no interaction with

Anyone know if this worth worrying about?  I'm not even sure
I see why/how closedir() should be calling pthread_mutex_destroy().

Adam D. Moss   . ,,^^   adam at   co:3
"Some of the statements we have made as CRASS make me shudder at the
  degree of naivete expressed, but I wouldn't put them down, ever, or
  say that any of them were wrong."

More information about the physfs mailing list