[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#161992: marked as done (libc6: Unlocking an unlocked and already destroyed mutex on fclose())

Your message dated Sun, 11 Feb 2007 23:28:50 +0100
with message-id <20070211222850.GA14482@hades.madism.org>
and subject line libc6: Unlocking an unlocked and already destroyed mutex on fclose()
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: libc6
Version: 2.2.5-6.0.1
Severity: normal
Tags: patch

(the version number 6.0.1 is from the privately built package with
this patch already applied.)

There is a bug in the fclose logic regarding the locking behaviour. It
currently works this way:

1. lock the file unless flags have _IO_USER_LOCK
2. clean everything up; includes destroying lock and setting flags to
   default, not including _IO_USER_LOCK
3. unlock the file unless flags have _IO_USER_LOCK

This patch does not correct the behavious entirely. It just fixes the
clearing of _IO_USER_LOCK. The other bug (first destroying the mutex,
then unlocking it) is not as important, because the destruction will
fail, so that is a memory leak if dynamic memory is associated with
mutexes, whilst this bug can do real harm, because on files with
_IO_USER_LOCK the mutex destruction actually succeeds, and the unlock
will unlock this destroyed mutex.

This is not an issue with linuxthreads, but for example with the pthread
emulation layer in wine, that actually does associate memory with mutexes
and frees it on destruction.


<<< userlock.dpatch
#! /bin/sh -e

# DP:Fixes clearing of _IO_USER_LOCK on close, unlocking an unlocked
# DP:and destroyed mutex.

if [ $# -ne 2 ]; then
    echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
    exit 1
fi
case "$1" in
    -patch) patch -d "$2" -f --no-backup-if-mismatch -p0 < $0;;
    -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p0 < $0;;
    *)
	echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
	exit 1
esac
exit 0

--- libio-old/fileops.c	Sun Aug 12 06:48:11 2001
+++ libio/fileops.c	Tue Aug 20 21:36:08 2002
@@ -182,7 +182,7 @@
 #endif
 
   _IO_un_link ((struct _IO_FILE_plus *) fp);
-  fp->_flags = _IO_MAGIC|CLOSED_FILEBUF_FLAGS;
+  fp->_flags = _IO_MAGIC|CLOSED_FILEBUF_FLAGS|(fp->_flags&_IO_USER_LOCK);
   fp->_fileno = -1;
   fp->_offset = _IO_pos_BAD;
 
>>>userlock.dpatch

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux achilles.karcher.de 2.4.18 #1 Don Aug 15 23:15:36 CEST 2002 i686
Locale: LANG=de_DE.ISO-8859-1, LC_CTYPE=de_DE.ISO-8859-1

--- End Message ---
--- Begin Message --- 
Version: 2.3.6.ds1-10

On Sun, Sep 22, 2002 at 10:48:13PM +0200, Michael Karcher wrote:
> Package: libc6
> Version: 2.2.5-6.0.1
> Severity: normal
> Tags: patch
> 
> (the version number 6.0.1 is from the privately built package with
> this patch already applied.)
> 
> There is a bug in the fclose logic regarding the locking behaviour. It
> currently works this way:
> 
> 1. lock the file unless flags have _IO_USER_LOCK
> 2. clean everything up; includes destroying lock and setting flags to
>    default, not including _IO_USER_LOCK
> 3. unlock the file unless flags have _IO_USER_LOCK
> 
> This patch does not correct the behavious entirely. It just fixes the
> clearing of _IO_USER_LOCK. The other bug (first destroying the mutex,
> then unlocking it) is not as important, because the destruction will
> fail, so that is a memory leak if dynamic memory is associated with
> mutexes, whilst this bug can do real harm, because on files with
> _IO_USER_LOCK the mutex destruction actually succeeds, and the unlock
> will unlock this destroyed mutex.
> 
> This is not an issue with linuxthreads, but for example with the pthread
> emulation layer in wine, that actually does associate memory with mutexes
> and frees it on destruction.

  Well I've seen no proof of that assertion in glibc2.3 and 2.5 are you
sure it's still the case ? mutexes seems to be deallocated cleanly to
me.

  As of _IO_USER_LOCK cleaning, well, after fclose a FILE* is not usable
anymore, right ? so I don't see a bug here.

  Hence closing the bug.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpZOJ2oT54vw.pgp
Description: PGP signature


--- End Message ---
Reply to: