On Tue, Mar 06, 2007 at 09:36:00PM -0500, Theodore Tso wrote:
> On Tue, Mar 06, 2007 at 02:05:38PM -0800, Steve Langasek wrote:
> > No strong opinion either way; I'm more concerned that the e2fsprogs upload
> > happens sooner rather than later, so that d-i RC2 doesn't get held up
> > waiting for it
On Wed, Mar 07, 2007 at 07:52:24AM -0500, Theodore Tso wrote:
On Wed, Mar 07, 2007 at 09:59:19AM +, Philip Armstrong wrote:
Those if(probe.thingy) guards are entirely redundant: free(p) is a
no-op if p is NULL.
I didn't use that particular patch, but one that uses a goto into the
standard
On Wed, Mar 07, 2007 at 09:59:19AM +, Philip Armstrong wrote:
>
> Those if(probe.thingy) guards are entirely redundant: free(p) is a
> no-op if p is NULL.
I didn't use that particular patch, but one that uses a goto into the
standard function exit/cleanup path.
However, e2fsprogs is still
On Tue, Mar 06, 2007 at 04:19:43PM +0100, Steinar H. Gunderson wrote:
diff -ur e2fsprogs-1.39+1.40-WIP-2006.11.14+dfsg/lib/blkid/probe.c
e2fsprogs-patched/lib/blkid/probe.c
--- e2fsprogs-1.39+1.40-WIP-2006.11.14+dfsg/lib/blkid/probe.c 2006-09-18
03:12:28.0 +0200
+++ e2fsprogs-patched/
On Tue, Mar 06, 2007 at 02:05:38PM -0800, Steve Langasek wrote:
> No strong opinion either way; I'm more concerned that the e2fsprogs upload
> happens sooner rather than later, so that d-i RC2 doesn't get held up
> waiting for it.
I'm uploading it now to unstable.
Thanks,
On Tue, Mar 06, 2007 at 10:44:55AM -0500, Theodore Tso wrote:
> OK, release managers, the memory leak primarily occurs in the device
> mapper probing code, and an additional leak when there is a partition
> which does not have a valid filesystem known to blkid. rpc.mountd is,
> as far as I know,
severity 413661 important
thanks
On Tue, Mar 06, 2007 at 02:08:43PM +0100, Steinar H. Gunderson wrote:
> (RMs: I'm unsure if this should be fixed for etch or not, given that I
> do not know of anything in etch that actually uses this library enough
> for it to leak. Feel free to downgrade or tag e
On Tue, Mar 06, 2007 at 04:54:41PM +0100, Steinar H. Gunderson wrote:
> On Tue, Mar 06, 2007 at 10:44:55AM -0500, Theodore Tso wrote:
> > Yikes, what blkid function is rpc.mountd calling all the time which is
> > causing this kind of memory leakage?
>
> blkid_probe_all_new() seems to be the one. I
On Tue, Mar 06, 2007 at 10:44:55AM -0500, Theodore Tso wrote:
> Yikes, what blkid function is rpc.mountd calling all the time which is
> causing this kind of memory leakage?
blkid_probe_all_new() seems to be the one. It happens at every mount and
umount, I believe; it's not like it's being called
On Tue, Mar 06, 2007 at 02:08:43PM +0100, Steinar H. Gunderson wrote:
> Package: libblkid1
> Version: 1.39+1.40-WIP-2006.11.14+dfsg-1
> Severity: grave
> Tags: patch
>
> (RMs: I'm unsure if this should be fixed for etch or not, given that I
> do not know of anything in etch that actually uses this
On Tue, Mar 06, 2007 at 02:08:43PM +0100, Steinar H. Gunderson wrote:
> Only in e2fsprogs-patched/debian: BUILD-BF
> Only in e2fsprogs-patched/debian: BUILD-STD
> Only in e2fsprogs-patched/debian: comerr-dev
> Only in e2fsprogs-patched/debian: comerr-dev.postinst.debhelper
Feh, I attached the wron
Package: libblkid1
Version: 1.39+1.40-WIP-2006.11.14+dfsg-1
Severity: grave
Tags: patch
(RMs: I'm unsure if this should be fixed for etch or not, given that I
do not know of anything in etch that actually uses this library enough
for it to leak. Feel free to downgrade or tag etch-ignore, of course
12 matches
Mail list logo
