From owner-freebsd-current Fri Aug 7 10:39:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14875 for freebsd-current-outgoing; Fri, 7 Aug 1998 10:39:15 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14842 for ; Fri, 7 Aug 1998 10:38:58 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA05889; Fri, 7 Aug 1998 10:37:44 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma005887; Fri Aug 7 10:37:26 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id KAA29957; Fri, 7 Aug 1998 10:37:26 -0700 (PDT) From: Archie Cobbs Message-Id: <199808071737.KAA29957@bubba.whistle.com> Subject: Re: memory leaks in libc In-Reply-To: <199808071721.NAA20680@khavrinen.lcs.mit.edu> from Garrett Wollman at "Aug 7, 98 01:21:21 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Fri, 7 Aug 1998 10:37:26 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG, bde@zeta.org.au, dg@root.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman writes: > No, you've missed the point entirely. *Any program which does enough > playing around with the environment to be harmed by this memory leak > is using a totally inappropriate interface.* I disagree with that statement! And I base my disagreement not on conjecture but on experience. Here's a REAL example.. suppose you have a program which runs as a daemon, and it's job is to display the time on some display. The display of the time is generated via strftime(3). The device this daemon is running on allows the timezone to be configured. In order to display the time in the correct timezone, every so often (every 30 seconds or so) this deamon must make sure that strftime() knows about the *currently set* timezone, not the timezone that was set when the daemon started (which could be arbitrarily long ago in the past). How can it possibly do this? The only way to get strftime() to acknowledge a change in timezone is to do something like this: unsetenv("TZ"); tzset(); setenv("TZ", "/etc/localtime", 1); tzset(); (if you don't believe me then read the source for tzset() et. al.) Guess what? Every 30 seconds this deamon is malloc()'ing a new malloc block. Your supposedly reliable device will crash in a matter of days when it exhausts all available memory because of the memory leak. There's nothing "totally inappropriate" about what the daemon is doing -- in fact, using setenv() is the only way to do what it wants to do, ie., get libc to acknowledge a timezone change. My point? I agree with you that a program that implements a relational database using setenv()/getenv() as a backend would be "totally inappropriate". What I'm saying is that not every program which suffers from the setenv() memory leak is doing something "totally inappropriate". -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message