From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glibc-bugs-return-1802-listarch-glibc-bugs=sources.redhat.com@sources.redhat.com>
Received: (qmail 10947 invoked by alias); 26 Feb 2005 21:29:24 -0000
Mailing-List: contact glibc-bugs-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:glibc-bugs-subscribe@sources.redhat.com>
List-Post: <mailto:glibc-bugs@sources.redhat.com>
List-Help: <mailto:glibc-bugs-help@sources.redhat.com>, <http://sources.redhat.com/lists.html#faqs>
Sender: glibc-bugs-owner@sources.redhat.com
Received: (qmail 10570 invoked by uid 48); 26 Feb 2005 21:29:09 -0000
Date: Sat, 26 Feb 2005 21:29:00 -0000
From: "qboosh at pld-linux dot org" <sourceware-bugzilla@sources.redhat.com>
To: glibc-bugs@sources.redhat.com
Message-ID: <20050226212906.770.qboosh@pld-linux.org>
Reply-To: sourceware-bugzilla@sources.redhat.com
Subject: [Bug libc/770] New: possible deadlock on double-free logging
X-Bugzilla-Reason: CC
X-SW-Source: 2005-02/txt/msg00242.txt.bz2
List-Id: <glibc-bugs.sourceware.org>

_int_free() (malloc/malloc.c), which is called from free() with arena mutex
locked, checks and eventually prints/logs error message.
So if malloc_printerr() handling do some malloc()/free() on the same memory
arena, deadlock can occur.
vsyslog() can call free() during tz manipulation.

Yes, this deadlock is triggered by buggy code.
But it's all inside libc, not caused by actual memory corruption.

-- 
           Summary: possible deadlock on double-free logging
           Product: glibc
           Version: 2.3.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: qboosh at pld-linux dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=770

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.