Skip Menu |
 

Download (untitled) / with headers
text/plain 2.2KiB
From schemers@slapshot.stanford.edu Tue Jul 15 14:43:32 2003
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by krbdev.mit.edu (8.9.3) with ESMTP
id OAA24772; Tue, 15 Jul 2003 14:43:32 -0400 (EDT)
Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.64.14.116])
by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6FIhV6G011160
for <krb5-bugs@mit.edu>; Tue, 15 Jul 2003 14:43:31 -0400 (EDT)
Received: (from root@localhost)
by smtp2.Stanford.EDU (8.12.9/8.12.9) id h6FIhUxb008559
for krb5-bugs@mit.edu; Tue, 15 Jul 2003 11:43:30 -0700 (PDT)
Received: from slapshot.stanford.edu (slapshot.Stanford.EDU [171.64.26.45])
by smtp2.Stanford.EDU (8.12.9/8.12.9) with ESMTP id h6FIhSrH008530
for <krb5-bugs@mit.edu>; Tue, 15 Jul 2003 11:43:28 -0700 (PDT)
Received: from slapshot.stanford.edu (localhost.localdomain [127.0.0.1])
by slapshot.stanford.edu (8.12.8/8.12.8) with ESMTP id h6FIhTj6018437
for <krb5-bugs@mit.edu>; Tue, 15 Jul 2003 11:43:29 -0700
Received: (from schemers@localhost)
by slapshot.stanford.edu (8.12.8/8.12.8/Submit) id h6FIhS7U018435;
Tue, 15 Jul 2003 11:43:28 -0700
Date: Tue, 15 Jul 2003 11:43:28 -0700
Message-Id: <200307151843.h6FIhS7U018435@slapshot.stanford.edu>
To: krb5-bugs@mit.edu
Subject: memory leak in krb5_{init,free}_context?
From: schemers@stanford.edu
Reply-To: schemers@stanford.edu
Cc:
X-send-pr-version: 3.99


Show quoted text
>Submitter-Id: net
>Originator:
>Organization:
Stanford University
Show quoted text
>Confidential: no
>Synopsis: memory leak in krb5_{init,free}_context
>Severity: serious
>Priority: medium
>Category: krb5-libs
>Class: sw-bug
>Release: krb5-1.3
>Environment:

System: Linux slapshot.stanford.edu 2.4.20-18.9smp #1 SMP Thu May 29 06:55:05 EDT 2003 i686 i686 i386 GNU/Linux
Architecture: i686

Show quoted text
>Description:
There seems to be a memory leak when calling krb5_init_context
followed by a krb5_free_context.
Show quoted text
>How-To-Repeat:

Run this program and top at the same time. The memory for the process keeps
growing and growing. Using /usr/kerberos from Red Hat 9 there is no leak,
while when using Kerberos 1.3 from MIT there is a leak.

#include <krb5.h>

int
main(int argc, char *argv[])
{
krb5_context ctx;
while (1) {
krb5_init_context(&ctx);
krb5_free_context(ctx);
}
}

Show quoted text
>Fix:
haven't investigated that far yet...
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1665] memory leak in krb5_{init,free}_context
From: Tom Yu <tlyu@mit.edu>
Date: Tue, 15 Jul 2003 17:24:27 -0400
RT-Send-Cc:
Show quoted text
>>>>> "schemers" == The RT System itself via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
schemers> There seems to be a memory leak when calling
schemers> krb5_init_context followed by a krb5_free_context.

This seems to be the result of add_error_table not checking whether
the error table it's adding is already present in the et_list.

Show quoted text
>> How-To-Repeat:

Show quoted text
schemers> Run this program and top at the same time. The memory for
schemers> the process keeps growing and growing. Using /usr/kerberos
schemers> from Red Hat 9 there is no leak, while when using Kerberos
schemers> 1.3 from MIT there is a leak.

Interesting. Is it possible that Red Hat 9 has a different com_err
library for its krb5 installation? I don't think any of the relevant
code in our tree has changed at all recently.

---Tom
Date: Tue, 15 Jul 2003 18:32:44 -0400 (EDT)
From: Ezra Peisach <epeisach@MIT.EDU>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1665] memory leak in krb5_{init,free}_context
Cc: krb5-prs@MIT.EDU
RT-Send-Cc:

Our code base has not changed in a while. I noticed this once...

krb5_init_context does initialize the error tables.

krb5_init_ets does an initiazlie_XXX_error_table() each time.
This calls add_error_table - this adds the error table to the list.

Note - this is with our com_err code.

Note2: nothing has changed in this code since 2001.

Note3: Probably when we modified init_context to initialize the error
tables (which is a good think - the error was introduced)

Now - usually - all our code calls init_context once or twice (i.e.
the internal gssapi krb5_context, the krb4 one, etc) - so no-one is
hurt.

In the example code - memory will leak.

While in theory - we could add a reference count for each error table,
krb5_free_ets does nothing...

A simple code change would be to lib/krb5/error_tables/init_ets to have
a simple reference count which is incremented when someone calls it -
and a decrement in free_ets would make sense - then have free_ets
release the error table if the count reaches zero.

Ezra
Download (untitled) / with headers
text/plain 1.4KiB
I noticed this while unit testing new code in our WebISO system to make
sure I matched up all the krb5 alloc/free calls. I'm pretty sure
it wasn't happening pre 1.3 with krb5 grabbed directly from MIT.

I've got some abstraction of the Kerberos library calls going on, so
doing a single krb5_init_context would be slightly painful, as I also
wouldn't want to resort to a static variable to hold it, assuming I
have no other place to hang it.

What about adding reference counting to {add,free}_error_table?
Not sure if thats the location you were suggesting, but that seems like
the place to put it. If the error_table passed in to add_error_table is
already in the list, then up the ref count. And in free_error_table,
decrement and garbage collect if need be.

That would at least cap the leak from calling add_error_table multiple
times on the same error table without a free_error_table.

Of course all this error table stuff is not thread-safe since it uses
static variable and no mutexes. Any work going on to make krb5/gssapi
thread safe?

thanks, roland (schemers@stanford.edu)

Show quoted text
> While in theory - we could add a reference count for each error table,
> krb5_free_ets does nothing...
>
> A simple code change would be to lib/krb5/error_tables/init_ets to have
> a simple reference count which is incremented when someone calls it -
> and a decrement in free_ets would make sense - then have free_ets
> release the error table if the count reaches zero.
>
> Ezra
From: epeisach@mit.edu
Subject: CVS Commit
* init_ets.c (krb5_init_ets): Only initialize error tables once -
so that init_conext/free_context loops do not result in memory
leaks.

I did not implement the remove error table functions - as a system
installed com_err library might not support remove_error_table that
exists in our trees com_err library.


To generate a diff of this commit:



cvs diff -r5.94 -r5.95 krb5/src/lib/krb5/error_tables/ChangeLog
cvs diff -r5.21 -r5.22 krb5/src/lib/krb5/error_tables/init_ets.c
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1665] CVS Commit
From: Sam Hartman <hartmans@mit.edu>
Date: Sun, 20 Jul 2003 15:49:09 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Ezra" == Ezra Peisach via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Ezra> I did not implement the remove error table functions - as a
Ezra> system installed com_err library might not support
Ezra> remove_error_table that exists in our trees com_err library.

I think anything that supports add_error_table will also support
remove_error_table.
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1665] CVS Commit
Date: Sun, 20 Jul 2003 16:35:02 -0400
From: Ezra Peisach <epeisach@MIT.EDU>
RT-Send-Cc:
Redhat's comerr - which comes from the e2fs programs - does not include
a remove_error_table function. The remove function - as far as I know
only exists in the kerberos com_err library... I will have to survey
and verify...

Ezra
Date: Mon, 21 Jul 2003 09:40:14 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Ezra Peisach via RT <rt-comment@krbdev.mit.edu>
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1665] CVS Commit
RT-Send-Cc:
On Sun, Jul 20, 2003 at 04:35:08PM -0400, Ezra Peisach via RT wrote:
Show quoted text
>
> Redhat's comerr - which comes from the e2fs programs - does not include
> a remove_error_table function. The remove function - as far as I know
> only exists in the kerberos com_err library... I will have to survey
> and verify...

E2fsprogs started supporting remove_error_table() in version 1.33,
which was released April 21, 2003. So distributions released before
that date will almost certainly not support remove_error_table();
newer distro's should eventually support it.

E2fsprogs 1.34 (not yet released, but there are work-in-progress
snapshots available and included in Debian unstable) will have drop-in
replacement interfaces for the Heimdall extensions as well.

- Ted
To: rt-comment@krbdev.mit.edu
Subject: e: [krbdev.mit.edu #1665] CVS Commit
From: Sam Hartman <hartmans@mit.edu>
Date: Mon, 21 Jul 2003 13:00:59 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Ezra" == Ezra Peisach via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Ezra> Redhat's comerr - which comes from the e2fs programs - does
Ezra> not include a remove_error_table function. The remove
Ezra> function - as far as I know only exists in the kerberos
Ezra> com_err library... I will have to survey and verify...

I don't think redhat's com_err is currently suitable as a system
com_err for Kerberos. The e2fsprogs com_err will have
remove_error_table in a future version. I believe such a version may
have already been released.
From: tlyu@mit.edu
Subject: CVS Commit
pullup from trunk


To generate a diff of this commit:



cvs diff -r5.91.2.2 -r5.91.2.3
krb5/src/lib/krb5/error_tables/ChangeLog
cvs diff -r5.20.2.1 -r5.20.2.2
krb5/src/lib/krb5/error_tables/init_ets.c