Your message dated Mon, 26 Jan 2004 07:42:26 -0800
with message-id <[EMAIL PROTECTED]>
and subject line [EMAIL PROTECTED]: Re: Malloc nit.]
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)

--------------------------------------
Received: (at submit) by bugs.debian.org; 7 Jan 2004 04:17:07 +0000
>From [EMAIL PROTECTED] Tue Jan 06 22:17:06 2004
Return-path: <[EMAIL PROTECTED]>
Received: from baldric.uwo.ca (baldric) [129.100.10.225] 
        by master.debian.org with esmtp (Exim 3.35 1 (Debian))
        id 1Ae4xB-0003gS-00; Tue, 06 Jan 2004 22:05:57 -0600
Received: from carlos by baldric with local (Exim 3.35 #1 (Debian))
        id 1Ae4pB-0006HV-00
        for <[EMAIL PROTECTED]>; Tue, 06 Jan 2004 22:57:41 -0500
Date: Tue, 6 Jan 2004 22:57:41 -0500
From: Carlos O'Donell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: without linuxthreads, malloc locking routines do not work on hppa
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Useless-Header: listen, love, accept, mindfullness, patience, and humility.
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 
        2.60-master.debian.org_2003_11_25-bugs.debian.org_2004_1_5 
        (1.212-2003-09-23-exp) on master.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no 
        version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2004_1_5
X-Spam-Level: 

Package: glibc
Version: 2.3.2.ds1-10
Severity: important

malloc's arena locking routines in glibc rely on simple locking
functions that assume lock taken is 1 and lock released is 0.
This is not the case for hppa, the architecture has only one
primitive locking instruction ldcw (load and clear word).

Any program using malloc and not linking linuxthreads may be prone
to livelock when malloc has to increase arena size. Other scenarios
include locking an object, followed by dlopen'ing libpthread, and
attempting to manipulate the lock after the dlopen.

On hppa this can cause squid to lockup at start or when creating cache
directories.

The solution was presented upstream, and accepted. Malloc now has
per-arch locking functions that can be overriden with malloc-machine.h.
hppa upstream provides its own implementation of malloc-machine.h

This removes "bug-iconv3" from the testsuite failures for hppa.

The solution is to integrate upstream changes for:

libc/linuxthreads/sysdeps/pthread/malloc-machine.h
libc/linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h
libc/nptl/sysdeps/pthread/malloc-machine.h
libc/sysdeps/generic/malloc-machine.h
libc/sysdeps/mach/hurd/malloc-machine.h

and libc/malloc/*

c.


---------------------------------------
Received: (at 226511-done) by bugs.debian.org; 26 Jan 2004 15:42:38 +0000
>From [EMAIL PROTECTED] Mon Jan 26 07:42:38 2004
Return-path: <[EMAIL PROTECTED]>
Received: from marge.v3.ca [216.66.20.89] 
        by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
        id 1Al8so-0006A6-00; Mon, 26 Jan 2004 07:42:38 -0800
Received: from marge.v3.ca (localhost [127.0.0.1])
        by marge.v3.ca (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id 
i0QFgQGF028430
        for <[EMAIL PROTECTED]>; Mon, 26 Jan 2004 07:42:26 -0800
Received: (from [EMAIL PROTECTED])
        by marge.v3.ca (8.12.11.Beta0/8.12.10/Debian-0) id i0QFgQ7A028429
        for [EMAIL PROTECTED]; Mon, 26 Jan 2004 07:42:26 -0800
X-Authentication-Warning: marge.v3.ca: jbailey set sender to [EMAIL PROTECTED] 
using -f
Date: Mon, 26 Jan 2004 07:42:26 -0800
From: Jeff Bailey <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Re: Malloc nit.]
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
X-EMSscan-MailScanner: Found to be clean
X-EMSscan-MailScanner-SpamCheck: not spam, SpamAssassin (score=-9.009,
        required 5, BAYES_00 -4.90, USER_AGENT_MUTT -4.11)
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_01_25 
        (1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no 
        version=2.60-bugs.debian.org_2004_01_25
X-Spam-Level: 

Forgot to cc: this to the bug report.  Sorry.  Closing this bug.

----- Forwarded message from Carlos O'Donell <[EMAIL PROTECTED]> -----

From: Carlos O'Donell <[EMAIL PROTECTED]>
To: Jeff Bailey <[EMAIL PROTECTED]>
Subject: Re: Malloc nit.
X-Useless-Header: listen, love, accept, mindfullness, patience, and humility. 
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at 
fep02-mail.bloor.is.net.cable.rogers.com from [24.43.33.92] using ID <[EMAIL 
PROTECTED]> at Mon, 26 Jan 2004 10:12:14 -0500
X-EMSscan-MailScanner: Found to be clean
X-EMSscan-MailScanner-SpamCheck: not spam, SpamAssassin (score=-9.009,
        required 5, BAYES_00 -4.90, USER_AGENT_MUTT -4.11)

> > http://sources.redhat.com/ml/libc-alpha/2003-09/msg00234.html
> > 
> > Is the minimal required fix if we don't take upstream changes.
> 
> I think perhaps I'm not being clear:  These changes are already in
> Debian's glibc.  You provided them as part of
> 50_glibc232-hppa-full-nptl-2003-10-22.dpatch and they went in for
> 2.3.2.ds1-7.
> 
> May I close the bug? =)

Oh... wait a second...
*carlos looks at the comments*

# Implement proper non-linuxthread locking:
# patches-2003-10-14/glibc23-32-hppa-thread-m
# patches-2003-10-14/glibc23-32a-hppa-thread-m

Yes, I'm being silly, you can close the bug, sorry it's hard to keep
straight the patches in debian and *not* in debian.

The "hppa-full-nptl-2003-10-22" patch adds two pieces, I got caught
thinking the first piece was the only applied hunk. The linuxthreads
piece adds the bit I was thinking about, that wouldn't work until later.
The other patch adds the correct information to thread-m.h, feel free to
close the bug. It's done.

linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h    |   73 ++
malloc/thread-m.h                                             |   22

c.

----- End forwarded message -----


Reply via email to