Melchior FRANZ wrote:
> valgrind reports this bug:
>
> pthread_mutex_destroy: mutex is still in use
> at 0x40523AB4: pthread_error (vg_libpthread.c:229)
> by 0x405249B5: __pthread_mutex_destroy (vg_libpthread.c:825)
> by 0x40625220: _IO_default_finish (in /lib/libc.so.6)
> by 0x406233F0: _IO_file_finish@@GLIBC_2.1 (in /lib/libc.so.6)
> by 0x4061ABED: _IO_fclose@@GLIBC_2.1 (in /lib/libc.so.6)
> by 0x83A9452: destroy (in /home/m/fgfs/FlightGear/src/Main/fgfs)
> by 0x83A9E36: gzclose (in /home/m/fgfs/FlightGear/src/Main/fgfs)
> by 0x833008F: gzfilebuf::close(void) (zfstream.cxx:156)
> by 0x805C6BF: fgInitFGRoot(int, char **) (/usr/include/g++/std/bastring.h:166)
> by 0x805261E: mainLoop(int, char **) (main.cxx:1435)
>
> Unfortunately, I am neither familiar with threading, nor do I have time to
> debug this within the next three weeks. Is there a threading expert
> around?
This error is happening deep inside the C library. It's trying to
destroy a lock associated (presumably) with a FILE* created by the
zlib code. There's no way FlightGear could possibly touch that lock
directly. My guesses are:
1.) This is a bug in glibc (destroying a lock on a live object)
2.) This is a bug in zlib (closing a file that is still in use
somewhere)
3.) This is a bug in FlightGear (closing a zlib stream that is still
being dealt with in another thread?)
Since 1 and 2 are beyond our reach, I'd look for all the places where
the zlib objects are dealt with and make sure the usage is
threadsafe. That being said, I've never so much as looked at that
code myself.
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
