Re: Is it possible to get a fix for libc6 and nfs-kernel-server into etch r1?
Glibc maintainers, what is your opinion on that?
On Fri May 11, 2007 at 14:00:17 +0200, Steinar H. Gunderson wrote:
> On Fri, May 11, 2007 at 01:25:07PM +0200, Rik Theys wrote:
> > Is there any chance to get a fix for #423369 and #423108, a memory leak
> > in both libc6 and nfs-kernel-server, into etch r1?
> FWIW, here is the proposed patch:
> --- nfs-utils-1.0.10/debian/changelog
> +++ nfs-utils-1.0.10/debian/changelog
> @@ -1,3 +1,17 @@
> +nfs-utils (1:1.0.10-6.etch1) stable; urgency=medium
> + * Backport two memory leak fixes from unstable that together could bring
> + down a busy rpc.mountd quite fast. (Closes: #423108)
> + * In add_name(), free() the old pointer in all code branches. The old code
> + did it only when the malloc() failed, which was an oversight.
> + * In client_compose(), free() the hostent structure returned before
> + exiting. Normally, gethostbyaddr() returns a pointer to a static
> + struct, but this hostent comes from either get_reliable_hostbyaddr() or
> + get_hostent(), both which return a pointer they privately xmalloc()ed,
> + which thus can and should be free()d.
> + -- Steinar H. Gunderson <firstname.lastname@example.org> Fri, 11 May 2007 12:18:46 +0200
> nfs-utils (1:1.0.10-6) unstable; urgency=medium
> * Give --with-tcp-wrappers to configure; for some reason it stopped being
> only in patch2:
> --- nfs-utils-1.0.10.orig/support/export/client.c
> +++ nfs-utils-1.0.10/support/export/client.c
> @@ -262,6 +262,7 @@
> name = add_name(name, clp->m_hostname);
> + free(he);
> return name;
> @@ -329,6 +330,7 @@
> strcat(new, ",");
> strcat(new, cp);
> + free(old);
> return new;
> I haven't uploaded it to stable-proposed-updates yet, since I'm not sure what
> the current versioning number scheme is.
> /* Steinar */
> Homepage: http://www.sesse.net/
> To UNSUBSCRIBE, email to debian-release-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
[root@debian /root]# man real-life
No manual entry for real-life